Why is health data different under POPIA?
Most personal information may be processed if you have a lawful ground under section 11. Health information works the other way around: section 26 prohibits processing information concerning a data subject’s health unless an exception opens the door. For a healthtech product there are two doors that matter. Section 27 holds the general exceptions — chiefly the data subject’s consent, but also processing required by law or necessary to establish or defend a legal claim. Section 32 is the health-specific authorisation: it permits medical professionals and healthcare institutions or facilities to process health data where necessary for the proper treatment and care of the data subject, and permits insurers, medical schemes and medical scheme administrators to process it where necessary for the administration of the practice or institution.
Notice who is on that list — and who is not. A GP practice, a hospital group, a medical scheme administrator: section 32 fits them, and a vendor processing records on their behalf as operator rides on their authorisation. A standalone wellness app, a fitness tracker, a nutrition coach with no practitioner in the loop: section 32 does not fit, and the product almost always stands on consent instead — which is why the consent architecture in a direct-to-consumer health product is not a formality but its entire lawful basis.
POPIA is also not the only layer. The National Health Act makes information about a user’s health status, treatment or stay in a health establishment confidential (sections 14–15), with disclosure permitted only in defined circumstances, and the HPCSA’s ethical rules bind the practitioners who use practitioner-facing products. A healthtech contract that complies with POPIA but causes the customer to breach the NHA or their professional rules has still failed the customer.
The healthtech contract stack
A healthtech product rarely lives on one document. The stack below is the typical full set — which of them you need, and how heavy each must be, depends on whether you sell to practices, to patients, or both.
Customer agreements with practices and hospitals
The core question is who the responsible party for the patient records is — usually the practice or health establishment, with the vendor processing as operator. That makes section 21 POPIA operator terms mandatory in the customer agreement: processing only on the customer's instructions, confidentiality, security, and breach reporting up the chain.
Patient-facing T&Cs + consent architecture
Where the product collects health data directly from individuals, consent must be granular (per purpose, not bundled), specific, informed, and genuinely withdrawable in the product. For children's health data, POPIA section 34 prohibits processing a child's personal information unless a gateway applies — in practice, consent from a competent person (a parent or guardian).
Operator chains + flow-down terms
Every sub-vendor that touches health records — hosting, analytics, messaging, transcription, backup — sits in the operator chain. Each needs section 21 terms flowed down at least as strict as those given to the customer, plus disclosure and approval mechanics so the practice knows who actually holds its patients' records.
Security schedule justified to the sensitivity
Section 19 requires safeguards appropriate to the risk — and the risk for health records is high, so the justified standard is higher: encryption at rest and in transit, access controls and audit logs, environment separation. The schedule should also cover section 22 breach duties, with contractual notification windows tighter than the statute's "as soon as reasonably possible".
Data location + section 72 for offshore hosting
Hosting or processing health records outside South Africa is a cross-border transfer under section 72 and needs a ground: typically a binding agreement with the foreign recipient imposing substantially similar protection, or the data subject's consent. The contract should state where the data lives, who approves relocation, and which transfer ground is relied on.
Secondary-use + research clauses
Using patient data beyond service delivery — product improvement, analytics, model training, research — needs express treatment. De-identification standards should be contractual (de-identified to the point the data cannot reasonably be re-identified), and genuine health research is ethics-committee territory that the agreement should flag rather than quietly authorise.
Integration agreements (HL7 / FHIR interfaces)
Interfaces with pathology labs, medical schemes, hospital systems and other platforms move clinical data between parties. The integration agreement should allocate liability for data errors — a wrong result mapped to the wrong patient is a clinical-risk event, not just a software bug — and define message standards, validation duties, and who corrects what.
Exit: continuity of the records
Health records cannot simply be deleted when the subscription ends — retention duties under the National Health Act and HPCSA record-keeping rules survive the contract, and the prescribed periods differ by record type, so confirm the applicable period for each category rather than assuming one number. The exit clause should guarantee export in a usable format, a transition window, and certified destruction only of what may lawfully be destroyed.
What do telehealth platforms need to get right?
The HPCSA has issued guidance on telehealth for the practitioners it regulates — covering, in general terms, the practitioner’s duties around patient identity, informed consent to a remote consultation, confidentiality, and proper record-keeping of the encounter. The guidance binds the practitioner, not the platform — but a platform that makes compliance hard will not keep practitioner customers, and a well-drafted platform agreement turns the guidance into product requirements.
Concretely, the platform should support verifying who is on each end of the consultation, capturing and storing the patient’s consent, keeping the consultation record (and any recording) within the confidentiality and security regime described above, and exporting records into the practitioner’s own filing system. Because the HPCSA’s position has evolved — notably around when a prior in-person relationship is expected — platform terms should oblige both parties to comply with the guidance as it stands from time to time, and the current version should be confirmed for your specific model rather than assumed.
What about AI in healthtech?
Diagnosis-support, triage and risk-scoring models add a further POPIA layer: section 71 restricts decisions based solely on automated processing where they affect a person to a substantial degree — and a decision about someone’s health almost always does. The safe architecture keeps a practitioner in the loop as a genuine decision-maker, not a rubber stamp, and the contracts should say so: the platform agreement positions the model’s output as decision support, and the customer agreement allocates who handles data-subject representations and who can interrogate or override the output.
If you are commissioning a custom clinical model rather than embedding an existing one, the build contract needs statistical acceptance criteria, training-data provenance and layered IP allocation on top of everything on this page — see the full guide to AI development agreements.
Frequently asked
Is health data "special personal information" under POPIA?
Yes. Information concerning a person's health is special personal information under section 26, and processing it is prohibited unless an exception applies. The two main gateways are section 27 — the general authorisations, most importantly the data subject's consent — and section 32, which specifically authorises medical professionals, healthcare institutions and facilities, insurers, medical schemes and their administrators to process health data where necessary for the proper treatment and care of the data subject or for the administration of the institution or practice. A healthtech vendor that fits neither gateway has no lawful basis to process health data at all — which is why the contract stack starts with identifying whose authorisation the product rides on.
Can a wellness or fitness app collect health data?
Usually yes, but almost always on consent. A wellness app is typically not a medical professional, healthcare institution, insurer or scheme administrator, so the section 32 authorisation does not fit — leaving section 27 consent as the realistic gateway. That makes the consent architecture the legal foundation of the product: consent must be specific to each purpose, informed, freely given, and withdrawable inside the app without losing unrelated functionality. Bundled "I agree to everything" consent for special personal information is the single most common defect in SA health-app T&Cs.
Who owns the patient records in a practice-management system?
The practice holds them. In POPIA terms the practice or health establishment is normally the responsible party for its patients' records, and the software vendor processes them as operator on the practice's instructions under a section 21 agreement. The vendor should claim no rights in the records beyond what is needed to deliver the service, and the contract should guarantee the practice full export of its records in a usable format on exit — a practice locked out of its own patient records has both a POPIA problem and a professional-conduct problem.
Can we host South African health data offshore?
Only with a section 72 ground. Transferring personal information outside South Africa requires, in practice, either the data subject's consent or a binding agreement with the foreign recipient that imposes protection substantially similar to POPIA — which is why offshore EHR hosting needs back-to-back contractual terms with the cloud provider, not just a tick in a console. Given the sensitivity of health records, the contract should also name the hosting jurisdictions and require approval before data is moved to a new one.
What about children's health data?
Two prohibitions stack. Health information is special personal information under section 26, and a child's personal information is separately protected under section 34 — so a paediatric or school-health product must satisfy a gateway for each. The practical route is consent from a competent person (a parent or guardian), built into the onboarding flow with age verification and a mechanism for the competent person to exercise the child's rights. Products aimed at minors should treat this as core architecture, not a checkbox.
Can we use patient data to improve our product?
Not by default. Purpose limitation means data collected to deliver care or run a practice cannot simply be repurposed for the vendor's product roadmap, and as operator the vendor may only process on the responsible party's instructions. The clean routes are express, separate consent, or proper de-identification — to the point the data cannot reasonably be re-identified, which is a high bar for rich clinical datasets. Anything that amounts to health research on patient data moves into ethics-committee territory and should be flagged and approved through that route, not authorised by a buried clause.
What are our duties if health data is breached?
Section 22 requires notification to the Information Regulator and affected data subjects as soon as reasonably possible after a compromise. In a healthtech stack the contractual layer matters as much as the statute: the operator agreement should oblige the vendor to notify the practice within a fixed, short window (commonly 24-72 hours) with enough detail for the practice to meet its own section 22 duties, and the National Health Act's confidentiality regime for health establishment records raises the stakes of any disclosure. Breach-response roles, forensics cooperation, and who communicates with patients should all be allocated before the incident, not during it.
What does a healthtech contract stack cost?
From R16,000 for a core stack — customer agreement with section 21 operator terms, patient-facing T&Cs with the consent architecture, and a security schedule. R25,000-R40,000 where the build includes integration agreements, offshore hosting under section 72, research or secondary-use clauses, or a multi-vendor operator chain. Reviewing an existing stack against POPIA's special-personal-information regime is typically R8,500-R12,500.