DrDoctor

DrDoctor is a cloud-based SaaS platform hosted primarily on Microsoft Azure. Production workloads run in Azure UK South, with resilience and other services configured in additional regions where applicable. DrDoctor has no on-premises production components. Patient data held in the DrDoctor production environment and its backups is hosted in the UK. Some sub-processors may process data outside the UK; where this occurs, the relevant transfer safeguards and processing locations are documented in the applicable Data Processing Agreement and sub-processor information.

We maintain a current sub-processor register covering the services provided, processing locations and relevant transfer safeguards. The applicable Data Processing Agreement and sub-processor information are the authoritative sources. Sub-processors are subject to appropriate contractual data protection obligations and are kept under review. The current information is available to trusts through the agreed customer-assurance process.

As a processor, we retain data in line with the Trust’s instructions and applicable retention schedule. At contract end, or earlier on the controller’s instruction where appropriate, we securely return, delete or anonymise data in accordance with the contract and agreed off-boarding process. The applicable time limit is set out in the contract or DPA.

The platform is operated by DrDoctor on Microsoft Azure, with core production hosting in the UK and no on-premises production components. Third parties involved in delivering the service are identified through the applicable sub-processor and contractual assurance process.

The healthcare provider remains the data controller and DrDoctor is the data processor. We process patient data only on the documented instructions of the healthcare providers we work with, subject to the agreed service and contract.

DrDoctor Tasks is registered with the MHRA as a Class I medical device (registration reference 2026052201494644). The regulatory status of other products is assessed separately according to their intended purpose; we do not represent other products as registered medical devices unless expressly stated. Registration is not the same as MHRA approval or certification.

We employ a Clinical Safety Officer (registered with the NMC) and apply DCB0129 across our health IT products. We maintain a clinical risk management system, including hazard logs and Clinical Safety Case Reports, with controls reviewed as products change and after relevant incidents.

We provide a DCB0160 support pack to help trusts complete their own clinical safety assessment, including hazards and controls that transfer to the deploying organisation. Our Clinical Safety Officer can support trust clinical-safety teams during deployment and, where agreed, thereafter.

Incidents are triaged for clinical-safety impact and reviewed through the clinical risk management process. Findings update the hazard log and drive corrective and preventive actions with the relevant product teams, so lessons are used to improve the product and its controls.

Patients are verified against details held in the trust’s patient record, and NHS Login is supported through our NHS App integration. Verification models differ by product and channel. Proxy access is controlled by the healthcare provider, which determines whether it is appropriate and how it is governed.

Healthcare providers control which services and clinic types are in scope. For higher-risk channels, we ask providers to exclude sensitive clinic types where appropriate. Safeguarding flags, proxy arrangements and related decisions remain with the providers, who know their patients and retain responsibility for their local processes.

The answer depends on the product and the role in which DrDoctor processes the data. We do not use patient-identifiable data, patient-sensitive data or staff-portal user-identifiable data processed on behalf of a Trust to train or fine-tune general AI models; our current AI policy prohibits submitting this processor-role data to AI tools or embedded AI features. Some product-specific models may use pseudonymised data under separate governance—for example, the DNA Predictor uses pseudonymised historic appointment data before it reaches the model. Any approved AI supplier must have documented controls covering training and related uses, and product-specific AI processing is subject to separate governance, security and data-protection assessment.

Where AI features are used, they are subject to clinical-risk management proportionate to their intended purpose, including the DCB0129 process where applicable. They are also subject to AI-specific safety evaluation and monitoring proportionate to the product and deployment. Clinical decisions remain with appropriately authorised healthcare professionals, and safeguards are applied to keep automated features within their defined scope.

Clinical decisions always remain with clinicians. Automated features handle administrative tasks within limits set by the trust, and anything outside those limits is escalated to staff. Accountability follows the DCB0129 and DCB0160 split: DrDoctor is responsible for the platform performing as specified, while the trust remains responsible for its clinical use and local clinical governance.

Call recording is product- and use-case-specific; we do not claim that all calls are recorded or that all audio is retained. Where recording is enabled, the applicable trust or service arrangement defines whether audio, a transcript or both are retained, together with the purpose, access controls and retention period. Callers are informed where recording and transparency requirements apply. Further details can be provided for the relevant product and deployment.

Our standard Service Level Agreement measures service availability against a contractual requirement of 99.9%. Service credits may apply if the agreed availability threshold is not met, subject to the exclusions and terms in the applicable SLA. The published SLA is available at drdoctor.co.uk/service-level-agreement. Availability is monitored operationally, and service or incident updates are provided through the agreed customer channels.

A documented Incident Management Policy governs investigation, containment, escalation, client notification and corrective-action logging. Any incident with actual or potential patient-safety impact is also reviewed by the Clinical Safety Officer through the clinical risk management process. Communication cadence and post-incident reporting follow the incident severity and applicable customer arrangements.

As a processor, we notify the trust as controller without undue delay and in line with the pre-agreed DPA and SLA timelines. The notification process supports the trust’s legal and regulatory obligations, including its assessment of whether a breach must be reported to the ICO within 72 hours of becoming aware of it.

Data is encrypted in transit using TLS 1.2 or higher and at rest using AES-256, with keys managed through Azure Key Vault where applicable.

Yes. We undergo annual penetration testing by CREST-certified testers. A letter of attestation or suitable executive summary can be made available on request; full technical reports are not published because they contain sensitive security information.

DrDoctor staff authentication uses single sign-on through Microsoft Entra ID, with multi-factor authentication and Conditional Access controls. Production access is role-based, time-limited and governed through Azure Privileged Identity Management.

Integrations use open, documented interfaces and standards appropriate to the use case, including HL7, FHIR, HTTPS and authenticated APIs. The exact interface and security controls depend on the integration.

DrDoctor is ISO/IEC 27001 certified, holds Cyber Essentials Plus, and achieved DSPT Standards Exceeded for the 2025–2026 submission. Certification and assessment scopes are available through the customer-assurance process.

Yes. ICNH Ltd, trading as DrDoctor, is registered with the Information Commissioner’s Office under reference Z3313550. The ICO register entry is available at ico.org.uk/ESDWebPages/Entry/Z3313550.

Our 2025–2026 Data Security and Protection Toolkit submission achieved Standards Exceeded. You can verify this on the public DSPT register using ODS code 8HY91.

Requests such as access or erasure are handled under our documented UK GDPR process, working with the trust as data controller. Where a patient contacts us directly, we verify and route the request to the relevant trust for a decision before data is removed, unless DrDoctor has an independent obligation to act.

The patient-platform privacy notice is at my.drdoctor.co.uk/privacy, and the website privacy notice is at drdoctor.co.uk/privacy-notice.

Not necessarily. The trust, as data controller, determines the lawful basis for using DrDoctor as part of care and service delivery; this will commonly be direct care rather than consent. Patients can manage applicable communication preferences, and opt-outs are respected before identifiable messages are sent where the service supports them.

These cohorts are managed through the provider’s own processes as controller, including safeguarding flags and proxy arrangements. The trust decides which services and patient groups are in scope and remains responsible for the relevant clinical, safeguarding and information governance decisions.