How the platform meets the conditions for lawful processing under the Protection of Personal Information Act, including for health and biometric information.
A scheme or administrator evaluating MedicalBytes has to satisfy itself that the platform lets it meet its own obligations under the Protection of Personal Information Act. This page sets out how, condition by condition, so a compliance officer can check it against their own assessment rather than take a general assurance on trust.
It complements the privacy notice. The privacy notice tells a member what happens to their information. This page tells a responsible party how the platform supports the duties it carries.
In almost every deployment the client scheme, insurer or administrator is the responsible party and SeptiBytes is the operator, processing only on documented instruction. Section 20 requires that relationship to be governed by a written contract, and section 21 requires the operator to secure the information and to notify the responsible party of any compromise. Both sit in the operator agreement signed at implementation.
Some activities have to be allocated deliberately rather than assumed, because practice differs between clients: membership onboarding, biometric enrolment, provider contracting and portal account issuing. The operator agreement sets out who is responsible for each.
The responsible party remains accountable. What the platform provides is the evidence: an immutable audit trail covering every login, override and record change with before and after state, role definitions that can be exported and reviewed, and reports showing who accessed what.
Processing is limited to what the purpose requires. Role-based access control scopes every user to the schemes, clients, branches and providers they may act on. Diagnosis and identifier masking removes clinical detail from users without a need to see it. Biometric consent is captured at enrolment, recorded against the member record, and can be withdrawn.
Each processing purpose is stated in the operator agreement and in the privacy notice. Retention is configured per client against the record-keeping obligations that client carries, and the platform enforces the configured period rather than leaving deletion to memory.
Data loaded for one client is never processed for another. Multi-client and multi-scheme separation is enforced at the data layer, not by convention. We do not use member or claims data to develop products for anyone else, and the aggregated statistics used to operate the platform cannot identify a person, a provider or a client.
Verified capture at source is the design principle the whole chain rests on: identity proved biometrically, entitlement resolved live, invoices read and coded rather than retyped. Plans and tariffs are effective-dated, so a historic claim is always evaluated against the rules in force on the date of service. Correction routes exist for members and providers, and a correction is itself audited.
The privacy notice is public and plainly written. Members are told at enrolment what biometric information is taken, why, and what happens if they decline. Where information is collected from a provider or employer rather than from the member, the responsible party notifies the member under section 18.
Encryption in transit and at rest; biometric templates encrypted separately and never stored as images; multi-factor authentication and single sign-on; segregation of duties enforced by the platform; approval ceilings per role and per user; tested backups and restores; and a documented incident response procedure. Section 22 notification of a compromise to the Regulator and to affected data subjects is made by the responsible party, with us supplying the forensic detail from the audit trail.
Access, correction and deletion requests are answered by the responsible party. The platform supports them with a complete per-member view, correction with audit, and deletion that respects the retention rules while preserving the financial record the law requires to be kept.
Health information and biometric information may not be processed unless an exclusion in section 27 applies. For a medical scheme the relevant ones are processing carried out by an administering body for its members, processing necessary for medical treatment or the administration of care, and the data subject's own consent.
The platform is built on the narrowest of these that will do the job. Biometric templates are used for one purpose: proving entitlement at the point of service. They are not shared, not reused, and not matched against any population outside the client's own for any purpose other than detecting duplicate enrolment.
Dependants include children, and their health information is processed under the authority of a competent person, ordinarily the principal member. Enrolment records who gave that authority. Employer and HR users never see a dependant's clinical information.
Member and claims data is held in South Africa. Cloud infrastructure, backup and tooling may involve facilities or support outside the Republic. Where personal information crosses a border it is on a section 72 basis: a binding agreement with the recipient upholding principles substantially similar to POPIA, including on onward transfer, or necessity for performance of the contract with the member. Clients requiring strict data residency in the Republic are configured that way, and it is recorded in their agreement.
Authorisations may be decided automatically against the client's own rules. Section 71 restricts decisions based solely on automated processing where they have legal consequences. The platform handles that in three ways: automatic decline is issued only on an explicit configured rule, anything uncertain is routed to a person rather than refused, and every automated decision records the rule that produced it so it can be explained and reviewed on request.
Member data is never used for direct marketing. Enquiries submitted on this website are used to answer the enquiry and are not added to a marketing list.
SeptiBytes Solutions has an appointed Information Officer, reachable at info@med-bytes.com marked for their attention. Each client responsible party has its own Information Officer for the information it controls.
Raise a concern with us first at info@med-bytes.com, or with the responsible party where the information belongs to a scheme. A data subject who remains dissatisfied is entitled to complain to the Information Regulator (South Africa); its current contact details are published at inforegulator.org.za.
Schemes assessing the platform may request the operator agreement template, the security architecture summary, the retention configuration guide and the incident response procedure. Ask at info@med-bytes.com.
SeptiBytes Solutions, for the MedicalBytes platform.
Effective 25 September 2026
