Nothing to leak, by design.
The most sensitive data in the workflow, patient identifiers and clinical findings, never persists on our servers. What we do hold is protected the way you would expect. This page is both the summary for your IT team and our formal Security and Data Handling statement.
Last updated: September 2026.
At a glance
Audio is deleted after processing
Encrypted in transit, transcribed, then discarded once the report is back on the clinician’s device.
No reports are stored
The finished report lives with you. There is nothing on our side to show anyone.
Operated under the NDPR
Based in Nigeria and governed by the Nigeria Data Protection Regulation.
Two-factor and device approval
Available on every account, mandatory where the organisation says so. New sign-ins wait for approval.
Sessions end on the server
“Sign out everywhere” ends every session immediately, not at the next refresh.
Never used to train models
Patient dictation and reports are not used to train AI models.
Security is central to how we design TScribe, Ureport and the platform behind them. Clinical information is sensitive by nature, and our architecture reflects that from first principles. This page describes the technical and organisational measures we use to protect your data and your patients’ privacy.
1. Encryption in transit
All communication between the applications, the browser extension, the organisation dashboard and our servers uses TLS 1.2 or higher. This applies to audio uploads, report retrieval and all account management operations. We do not accept unencrypted connections.
2. Audio data handling
When you submit audio for transcription, it is transmitted over an encrypted connection to our processing service. Once the transcription is complete and the report draft is returned to your device, the audio is deleted from our systems. We do not cache, archive or store raw audio recordings. Live captions shown while you speak are display-only and are never stored or billed.
3. Patient data
The platform is built so that patient-identifiable information does not persist on our servers. Reports are generated, returned to the user’s device, and not stored by us. If you include patient names or identifiers in your dictation, those are present only in the transient processing pipeline and are not retained after the session completes.
4. Account data
Account details (name, email, specialty, organisation membership) are stored in encrypted databases hosted in secured environments. Passwords are hashed using modern one-way algorithms and never stored in plaintext. We implement rate limiting on sign-in endpoints to prevent brute-force attacks.
5. Access controls
Access to production systems is restricted to authorised personnel on a need-to-know basis. We use multi-factor authentication for all internal system access. Audit logs are maintained for administrative operations.
6. AI model training
We do not use patient dictation content or clinical reports to train AI models. The AI pipeline processes your audio to generate a report and then discards the input. Model improvements are based on aggregated, anonymised usage signals unconnected to any patient data.
7. Account protection
Two-factor authentication is available on any account and can be made mandatory on organisation staff accounts, which cannot then turn it off. New sign-ins from an unrecognised device wait for approval. Sign-in attempts are rate limited per account and per address. Changing your password signs out every other device immediately rather than at each one’s next refresh. You can see and revoke your active sessions from the app, and “sign out everywhere” ends every session on the server.
8. Organisation controls
An organisation’s owner and administrators can approve or revoke devices, lock the organisation to approved devices, require two-factor for all members, set per-member credit limits, remove members and delete accounts they administer. Administrators can see members, usage and devices. They cannot see reports, recordings or dictation, because we do not hold that content.
9. Files you send us
Any file attached to a support message is written to a quarantine area that nothing serves, and is not readable by anyone until it has been checked. Images are re-encoded from their pixels, which removes anything hidden inside the file rather than trying to detect it. Documents are scanned before release. A file that cannot be checked is refused rather than accepted unchecked.
10. Records system connections
Where an organisation files reports into its own records system over HL7 FHIR, SMART on FHIR or the on-premise agent, the connection is authenticated with credentials that organisation controls and can rotate or revoke at any time from its dashboard. Revoking takes effect immediately. We log that a report was sent and when; we do not log or retain its clinical content.
11. The browser extension
The UnityPulse Dictation extension reads and writes only the field you dictate into, on the page you are on, when you ask it to. It does not read pages in the background and does not send page content to us. Its session, settings, templates and interrupted drafts are stored in the browser’s extension storage on your device. The extension privacy notice has the detail.
12. Sub-processors
We use a limited set of third-party processors: AI transcription and language providers (audio in, draft out, nothing retained), payment processing, email delivery and hosting infrastructure. Each is selected to minimise data exposure and is bound by its own privacy and security terms. The website uses Google Analytics; the applications do not embed third-party trackers, advertising pixels or social media widgets.
13. Regulatory alignment
Unitypulse is based in Nigeria and operates under the Nigeria Data Protection Regulation (NDPR). Our handling of clinical audio and account data is designed to align with the principles of the HIPAA privacy and security rules for organisations that ask for it, although we are not a United States covered entity. Because reports and audio are not retained, most data-residency and retention questions have a short answer: the data is in your system, not ours.
14. Incident response
We maintain an incident response plan for security events. In the event of a confirmed data breach affecting user account data, we will notify affected users and, where an organisation account is involved, its administrators, within the timeframe required by applicable law, including the NDPR (72 hours for notifiable breaches where applicable).
15. Reporting vulnerabilities
If you discover a security vulnerability in any UnityPulse product, please contact us responsibly at hello@unitypulse.io. We will acknowledge your report within two business days and work with you to address the issue before any public disclosure.
16. Contact
Security questions from hospitals and IT teams: hello@unitypulse.io or the contact page. See also the Privacy Policy and data deletion pages.