Privacy Policy
Effective date: 1 January 2026. This policy explains how Digital Health Identity collects, uses, shares, and protects information in healthcare identity services.
1. Introduction and scope
Digital Health Identity operates digitalidentityx.com and related verification APIs designed for patients, caregivers, clinicians, and healthcare organisations. Because our core purpose involves health-related identifiers and consent metadata, we apply privacy practices stricter than generic consumer websites.
This policy covers information collected through websites, mobile-responsive portals, partner integrations, support correspondence, and in-person verification sessions at participating clinics. Separate notices may apply to research sub-studies requiring ethics board approval.
2. Information we collect
2.1 Identity and demographic data
We collect legal and chosen names, birth dates, gender markers, government identifiers where permitted, addresses, contact emails, mobile numbers, emergency contacts, language preferences, and interpreter requirements. Guardian relationships and delegated access designations are stored with effective date ranges.
2.2 Clinical linkage metadata
We store references linking your profile to external medical record numbers, laboratory accession codes, imaging study identifiers, and appointment confirmations. Full clinical documents remain primarily at source institutions unless you authorise copies within our vault.
2.3 Consent and audit records
Every permission grant, revocation, break-glass event, and staff lookup generates immutable audit entries including timestamp, organisation, user role, stated purpose, and data categories accessed. These logs support patient transparency and regulatory inspections.
2.4 Technical information
Servers record IP addresses, browser types, device identifiers, session tokens, and API call patterns for security monitoring. We minimise retention of raw logs, aggregating statistics after defined periods unless investigations require extended preservation.
2.5 Payment and billing
Individual memberships and organisation invoices involve payment processor tokens rather than full card numbers stored on our systems. Billing contacts and tax identifiers for enterprise customers are handled under separate financial privacy controls.
3. How we use information
Primary uses include verifying identity, preventing duplicate records, enforcing consent scopes, facilitating appointments, validating practitioner credentials, delivering notifications about access events, improving matching algorithms through de-identified quality metrics, and complying with lawful requests.
We do not use identifiable health metadata for unrelated advertising or sale to data brokers. Product analytics rely on aggregated, de-identified datasets unless you opt into specific research programmes with independent consent.
4. Legal bases for processing
Processing rests on patient consent for optional sharing, contractual necessity for organisations purchasing services, legitimate interests in fraud prevention and network integrity, and legal obligations such as mandatory breach notification or court orders compatible with healthcare privacy law.
Where regulations require explicit consent—for sensitive categories like mental health segment flags—we collect affirmative confirmations separate from general terms acceptance.
5. Sharing with healthcare partners
Participating clinics, hospitals, laboratories, imaging centres, and authorised caregivers receive only the data categories you approve. Sharing stops immediately upon revocation except where retention is required for ongoing treatment continuity or billing disputes you initiate.
Integration vendors acting as processors must sign data protection agreements limiting use to contracted functions and mandating breach notification within strict timelines.
6. Sharing with other categories
We may disclose information to professional advisors under confidentiality duties, auditors verifying security controls, payment processors completing transactions, and authorities when legally compelled after reviewing scope and objecting to overbroad demands where permitted.
Corporate reorganisations involving asset transfers will continue protections through successor agreements and patient notification before control changes affect processing purposes.
7. International transfers
Data may be processed in secure facilities across regions where partner hospitals operate. Transfers employ encryption, access minimisation, and standard contractual clauses or equivalent safeguards recognised under applicable healthcare privacy frameworks.
8. Retention
Active profiles remain while accounts exist. Closed accounts trigger deletion schedules for non-mandatory fields after export windows expire. Audit logs and consent histories may persist longer where regulations require proof of authorised access for malpractice or billing investigations.
Backup media rotate on encrypted cycles with defined destruction dates. Legal holds pause deletion when litigation or regulatory inquiries are pending.
9. Security measures
Controls include TLS encryption, role-based access, hardware security modules for sensitive keys, annual penetration testing, workforce privacy training, and incident response playbooks practising containment within hours of confirmed breaches.
Patients should enable multi-factor authentication, monitor access logs, and report suspicious emails impersonating Digital Health Identity before entering credentials.
10. Your rights
Depending on jurisdiction, you may access copies of personal data, correct inaccuracies, restrict certain processing, export portable archives, object to specific uses, withdraw marketing consent, and lodge complaints with supervisory authorities.
Requests are verified through identity confirmation procedures to prevent fraudulent disclosure. We respond within statutory timelines, extending only when complexity requires additional weeks with explanatory notice.
11. Children and dependents
Guardians manage profiles for minors and dependent adults. Adolescents approaching capacity may receive gradually expanding self-management privileges aligned with clinical guidance and local consent maturity standards.
12. Biometric data
When partner sites capture biometrics for high-assurance verification, templates convert to non-reversible representations stored separately from demographic tables. Opt-out alternatives exist where regulations mandate except for narrowly defined high-risk encounters.
13. Cookies and similar technologies
Essential cookies maintain authenticated sessions and security tokens. Analytics cookies, if enabled, use aggregated metrics without cross-site advertising profiles. Browser settings can limit non-essential cookies though some features may degrade.
14. Marketing communications
Newsletter subscriptions require email confirmation. Unsubscribe links appear in every promotional message. Transactional notices about appointments or security events are not marketing and cannot be disabled without closing clinical identity services.
15. Automated decision-making
Probabilistic matching suggests duplicate candidates; human specialists review merges. No fully automated decisions deny emergency care solely based on identity scores. You may request manual review of matcher outcomes affecting your profile linkage.
16. Changes to this policy
Material updates will be posted here with revised effective dates and highlighted summaries in patient dashboards. Continued use after notice periods constitutes acceptance unless regulations require re-consent for expanded processing purposes.
17. Data protection impact assessments
We conduct periodic assessments when launching features that materially affect identity matching, biometric storage, or cross-border replication. Summaries of mitigation measures appear in transparency reports without exposing security-sensitive implementation details that could aid attackers.
18. Processor oversight
Subprocessors handling infrastructure, monitoring, or support tickets undergo due diligence reviews and contractual flow-down obligations. An updated subprocessor registry is available to organisation customers upon authenticated request.
19. Breach notification
Confirmed breaches affecting personal data trigger notifications to patients, organisations, and regulators within timeframes mandated by applicable healthcare privacy law. Notices describe categories of data involved, likely consequences, and remediation steps such as credential resets or enhanced monitoring.
20. De-identification standards
When producing datasets for quality improvement or research, we remove direct identifiers and apply statistical disclosure controls such as cell size thresholds and date shifting where appropriate. Researchers must agree not to attempt re-identification and to destroy datasets after approved study completion unless retention is mandated by ethics committees.
De-identification review boards evaluate proposed releases before distribution, documenting risk assessments and approved recipient lists. Patients enrolled in optional research programmes may request summaries of studies their contributions supported after publication embargoes lift.
We prohibit linkage of de-identified datasets with commercial marketing files and audit recipient compliance through periodic certification renewals.
21. Contact our privacy office
Submit privacy inquiries through the website contact form with the subject line Privacy Request. Organisations may designate data protection liaisons for processor coordination documented in enterprise agreements.
Digital Health Identity