DPIA Support for Practices

Unpack is a communication, coaching, reflection, transcription and analysis service used by practices and individual professionals.

• Where a practice chooses to, patient conversations can be recorded in the app or imported. Audio is transcribed, the transcript is analysed to produce structured coaching and reflection outputs, and those outputs build a longitudinal history used for review and preparation.
• Unpack is designed for documentation, retrieval of previously discussed information, communication analysis and professional development. It is not intended to diagnose, prevent, monitor, predict, prognose, treat or alleviate disease or injury; determine patient-specific treatment suitability; or recommend patient-specific treatment, medication, investigation, dosage or referral. Clinical decisions remain with the treating clinician, and Unpack does not replace clinical record-keeping.
• Roles: the practice is normally the Controller for practice-directed patient and staff content; Azimuth Associates LTD t/a Unpack acts as Processor under the Data Processing Agreement. Azimuth Associates LTD is a separate controller for account, administrative, billing, security and legal-compliance data, as set out in the Privacy Policy.

People:

• patients and other conversation participants where a practice records or imports content;
• practice staff, clinicians and other Unpack users;
• coaches, appraisers and meeting participants where those features are used.

Data:

• audio recordings and imported audio;
• transcripts and cleaned transcripts;
• health and clinical information where it appears in conversation content — special-category data;
• account, profile and contact data; practice membership and role data;
• generated analyses, behavioural and patient-experience observations, coaching outputs;
• uploaded files and diary images;
• technical, authentication, application and administrative audit logs;
• push notification device tokens.

The purposes the service is built for are reflection on communication, coaching, improving how conversations go, and preparation informed by history.

The practice must articulate its own specific purpose, and its own assessment of necessity and proportionality. A generic “to improve communication” is unlikely to be enough on its own.

Recording in Unpack is not necessary for the delivery of dental care. Patient care can continue perfectly well without any conversation being recorded, and that should be reflected honestly in the necessity assessment.

1. A user starts a recording in Unpack on their device, or content arrives through an import or an inbound integration the practice has set up itself.
2. Audio and content are received by the Unpack application, which is built and hosted on the Lovable platform.
3. Audio, transcripts, accounts and application records are stored in Supabase, which also provides authentication and file storage.
4. Audio is sent through the Lovable AI Gateway to OpenAI for speech-to-text transcription.
5. The resulting transcript is stored in Supabase.
6. Transcript and conversation text are sent through the Lovable AI Gateway to Google Gemini models for analysis, structuring and coaching outputs.
7. Generated outputs are stored alongside the session or meeting they belong to.
8. Authorised users — the account holder, and coaches or practice roles where the practice has granted access — read that content through the application, subject to authentication and row-level access policies.
9. Source audio is deleted after successful processing. Failed-audio expiry is designed for seven days, but the scheduled sweep was missing at audit; verified remediation remains outstanding. Other content is removed by user deletion or by account purge, according to the retention lifecycle.

Firebase Cloud Messaging is used only for delivering push notifications to registered devices. It receives device tokens and the notification content itself — titles and short summaries — and is not part of the transcription or analysis chain. Where a notification summary is generated from content, that summary text passes through the notification delivery chain.

Full provider detail is in the Subprocessor Register.

We do not claim UK-only hosting. What we state is the architecture — which providers are used and for what. The processing region of each provider, and the transfer mechanism that applies to it, sit with those providers and are not verified directly by us.

• Provider-level terms have been located for our main providers, including transfer mechanisms based on the EU standard contractual clauses as amended by the UK Addendum.
• Whether those mechanisms flow through to Azimuth Associates LTD’s actual arrangement — in particular where model calls are made through the Lovable AI Gateway rather than under a direct account with the model provider — is not verified directly by us.
• The Unpack account is currently on the Lovable Pro plan. Lovable states that DPA inclusion applies to Business or Enterprise plans, and the model-training opt-out available on Business is not available to this Pro account. Unpack does not submit content for the purpose of training models, but no contractual training exclusion or formal DPA is claimed on this plan. Written clarification confirms that identifiable patient recordings and transcripts are restricted under all standard Lovable plans, including Business. Expansion remains on hold pending a negotiated exception or independently contracted processing and legal review; practice approval cannot override this restriction.
• The Supabase database, authentication and file storage region has been verified as AWS eu-central-1 (Frankfurt, Germany).
• The processing locations used by the Lovable AI Gateway and the downstream model providers are determined by those providers and are not verified directly by us. No UK-only claim is made for that part of the chain.

The current position for each provider is recorded in the Subprocessor Register. A practice should treat those outstanding items as an open risk to accept or challenge.

• Stored audio: deleted as soon as processing has completed successfully; failed or orphaned audio has a designed seven-day expiry, but the scheduled sweep was missing at audit. Verified remediation remains outstanding; no seven-day guarantee is made.
• Account deletion: a 30-day grace period, after which the account and its content are purged. Implemented.
• Transcripts, analyses and history: kept while the account is active, until deleted by the user or removed on purge.
• Provider backups and provider log rotation periods are set by those providers and are not verified directly by us.
• Admin audit records and account-deletion audit records are retained with no expiry set.

Full detail is in the Retention Schedule.

• Authenticated access, with row-level access policies enforced in the database.
• Encryption of data in transit using TLS; encryption at rest provided by the platform providers.
• Secrets held and used server-side, not in the client application.
• Multi-factor authentication enforced for administrative accounts.
• Privileged support access is MFA-gated, requires a stated reason, and is written to a tamper-resistant admin audit log that no client can write to or amend.
• Deletion controls for users, plus the audio sweep and account purge lifecycle.
• Consent confirmation gate before recording; no background listening.
• Optional on-device biometric lock in the iOS app.

Stated limitations. There is no application-level or end-to-end encryption of transcripts beyond the encryption provided by the platform providers; our administrators can technically access stored content. We hold no ISO 27001, Cyber Essentials or SOC 2 certification, and we have not had an independent penetration test. We say so plainly rather than implying assurance we do not have.

Full detail is in the Security & technical measures statement.

These are prompts, not a scored risk assessment. We deliberately do not assign probability or severity ratings — that is the controller’s judgement for its own setting.

• What is our Article 6 lawful basis for recording and processing this content?
• What is our Article 9 condition for the health data in patient transcripts?
• What exactly is the purpose, stated in a sentence we would be comfortable showing a patient?
• Is recording necessary for that purpose, and is it proportionate?
• Is there a less intrusive alternative that would achieve enough of the benefit?
• How will patients and staff be told, and where is that written down?
• How does a patient decline, and how do we ensure refusal carries no disadvantage?
• Who will have access, under what role, and how is access removed?
• How long will we keep transcripts, analyses and history, and who enforces that?
• How will we handle access, erasure, objection and rectification requests?
• Do we accept the supplier position, including the outstanding transfer and contractual items in the subprocessor register?
• What is our incident and breach process, and who owns it?
• Have we consulted our DPO or data-protection adviser, and recorded their view?
• Is the residual risk high enough that prior consultation with the ICO is required before we proceed?

• Data Processing Agreement — published in full for your legal review.
• Subprocessor Register.
• Retention Schedule.
• Security & technical measures.
• Patient Recording Guidance.
• Privacy Policy.

Operator: Azimuth Associates LTD t/a Unpack, Francis House, Coventry Road, Burbage, Leicestershire LE10 2HL. Registered with the Information Commissioner’s Office, registration number ZB497244. ICO registration is part of our data-protection governance; it is not a certification of GDPR compliance.

These sections are for the practice’s own record. Azimuth Associates LTD t/a Unpack does not sign, approve or countersign a practice DPIA.