This Data Governance Statement explains the governance and technical controls Prima Edge Health (Pty) Ltd ("PrimaEdge") applies to personal and health information processed through its website, app and related health and wellness services. It should be read with PrimaEdge's Privacy Notice, POPIA Consent Notice, Member/App Terms, Employer Services / Commercial Terms and PAIA Manual.
This Statement describes the current governance framework and system controls known to PrimaEdge. It does not replace the Privacy Notice, create a new consent requirement, or give a participating Employer access to individual Member health information.
1.1 This Statement applies to information processed through the PrimaEdge app and website, including information relating to Members, authorised PrimaEdge clinical and administrative personnel, participating Employer users and persons who submit website enquiries.
1.2 PrimaEdge's governance framework is intended to protect confidentiality, integrity and availability; support lawful health and wellness services; preserve appropriate Member control; separate individual Member information from Employer-level reporting; and provide accountable controls for access, security, retention, operators, research and data-subject rights.
2.1 PrimaEdge's current system architecture uses a single MySQL 8.4 LTS database environment for the app and the website contact-form data, with website enquiry information maintained separately from clinical Member information within the data structure.
2.2 Depending on the relevant service or interaction, information held may include:
2.3 The Privacy Notice provides the fuller public description of information categories, sources, processing purposes and lawful grounds.
3.1 PrimaEdge's current operating model is that the production database containing Member information is hosted in South Africa.
3.2 Production hosting provider: TO CONFIRM. Secondary / off-site backup location: TO CONFIRM. Routine production access from outside South Africa (if any): TO CONFIRM.
3.3 Any proposed routine storage of, or access to, personal information from outside South Africa must be assessed before implementation and handled in accordance with applicable transborder-information requirements.
4.1 Staff passwords and Member PINs are hashed using scrypt before storage. PrimaEdge's system does not store or retrieve them in plaintext. A forgotten credential is reset rather than disclosed.
4.2 Login sessions use signed session tokens capable of individual revocation before ordinary expiry, including where a credential is reset, an account is disabled or suspicious activity requires access to be terminated.
4.3 Current login-code delivery mechanism: TO CONFIRM. Current messaging / OTP provider (if any): TO CONFIRM.
5.1 Biometric and mental-health readings and generated export files are stamped with an HMAC-SHA256 cryptographic integrity value using a secret maintained separately from the database.
5.2 This control is used to detect alteration of a record after capture. It is an integrity control and is not represented as an absolute guarantee that alteration is technically impossible in every circumstance.
5.3 The system applies validation to biometric readings and rejects values outside configured physiologically plausible ranges before they enter a Member's permanent health record, reducing the risk that obvious input errors or implausible device readings are treated as valid clinical data.
6.1 Database backups are encrypted using AES-256 before being written to storage, and the backup process is configured not to proceed without the required encryption key.
6.2 The current system retains the last 30 backups. Production backup location: TO CONFIRM. Secondary / off-site storage arrangement (if any): TO CONFIRM.
6.3 Production TLS/HTTPS configuration: TO CONFIRM.
7.1 Access is role-based and is intended to be enforced through the system, not merely through internal policy.
7.2 Under the current architecture:
7.3 Access rights should remain limited to the authorised function of the relevant role. Material changes to roles or privileges must be assessed as part of change governance.
8.1 Employer sponsorship, procurement or payment for the Service does not, by itself, entitle the Employer to individual Member health results or health information.
8.2 Subject to applicable law and relevant Member choices, Employer reporting uses aggregated and appropriately de-identified health and wellness information designed not to disclose individual Member health results.
8.3 The system applies an additional safeguard under which a statistic representing fewer than 10 Members is suppressed rather than reported. This threshold is an additional operational safeguard and is not, by itself, treated as establishing anonymity.
8.4 PrimaEdge may apply further controls, including suppression, grouping or generalisation, where small cohorts, segmentation, repeated reports, trend comparisons or information already known to an Employer could create a material re-identification risk.
8.5 Employers are not permitted to reverse engineer, infer, match or re-identify individual Members from aggregated or de-identified reporting, circumvent PrimaEdge access controls, or use PrimaEdge reporting for an unlawful discriminatory, disciplinary or other employment purpose.
9.1 PrimaEdge distinguishes contractual acceptance of the Member/App Terms, POPIA consent for a specified processing activity, and clinical informed consent where required.
9.2 The current consent architecture records three separate choices, where applicable: medical-scheme submission; Employer reporting; and research, statistical analysis, trend analysis and population-level health insights.
9.3 Consent choices are tracked independently. The system is designed to record the grant or withdrawal of a choice, the time of that action and the version of the applicable notice.
9.4 For a consent-dependent medical-scheme submission, declining or withdrawing the applicable consent prevents future submissions under that consent. This does not prevent processing or disclosure otherwise permitted or required by law.
9.5 Member-selected medication or health reminders are treated as Member-selected service functionality and are not, merely by being reminders, a fourth POPIA consent category. Any future messaging channel that creates a distinct consent or communications requirement must be assessed before implementation.
10.1 PrimaEdge's current service model is intended to maintain a longitudinal Member health history where legally and operationally appropriate.
10.2 A Member's record is not automatically destroyed because employment with a participating Employer ends or the Employer's commercial arrangement with PrimaEdge terminates.
10.3 The Member may be separated from the former Employer's active population while retaining historical health information subject to applicable law, technical capability and service arrangements. The former Employer does not thereby acquire access to individual health information.
10.4 If the Member later becomes eligible through another participating Employer, an existing profile may, where appropriate, be associated with the new programme in accordance with the Privacy Notice, applicable Member choices and law. That association does not, by itself, entitle the new Employer to individual historical health information.
11.1 PrimaEdge may use hosting, infrastructure, email or login-code delivery, technical-support, backup, communications, CRM, professional or other service providers where required by the production model.
11.2 A provider that processes personal information on PrimaEdge's behalf must be subject to appropriate confidentiality, security and contractual controls, and its access should be limited to what is required for the authorised function.
11.3 Active SMS integration (if any): TO CONFIRM. Active WhatsApp integration (if any): TO CONFIRM. Active CRM integration (if any): TO CONFIRM. Relevant provider(s): TO CONFIRM.
11.4 PrimaEdge will maintain an appropriate internal register of material operators and service providers, their processing functions and relevant contractual/security arrangements.
12.1 PrimaEdge may use appropriately de-identified information for research, statistical analysis, trend analysis and population-level health insights where the relevant Member choice and applicable legal requirements permit.
12.2 Research and analytical outputs must be governed to reduce re-identification risk and must not identify an individual Member in external publication or disclosure unless a separate lawful basis exists and applicable requirements are satisfied.
12.3 Any future external research collaboration, institutional access or publication arrangement must be assessed for applicable privacy, confidentiality, contractual, ethical and governance requirements before implementation.
13.1 PrimaEdge retains information for periods justified by the purpose for which it is held, applicable legal and professional requirements, health-record continuity, legitimate operational requirements and the rights and interests of Members.
13.2 Category-specific periods for health information, access logs, backups, consent records, website enquiries and other records are to be maintained in PrimaEdge's internal Data Retention Schedule. A single universal retention period is not applied merely for convenience.
13.3 The system's current retention of the last 30 encrypted backups is a technical backup-cycle control and does not, by itself, determine the legal retention period applicable to the underlying records.
13.4 When information no longer has a lawful or justified retention basis, PrimaEdge will apply an appropriate deletion, destruction, de-identification or archival outcome in accordance with the applicable record category and legal requirements.
14.1 PrimaEdge seeks to maintain information that is reasonably complete, accurate, not misleading and updated where necessary for its purpose.
14.2 Members may request access to or correction of personal information through the channels described in the Privacy Notice and PAIA Manual.
14.3 Where a record forms part of a clinical or professional history, correction may require an appropriate amendment or audit history rather than silent deletion or overwriting of the original record.
15.1 PrimaEdge will maintain an internal process for identifying, escalating, containing, investigating and documenting suspected or confirmed unauthorised access to or acquisition of personal information.
15.2 Where applicable notification requirements are triggered, PrimaEdge will address notification to the Information Regulator and affected data subjects in accordance with applicable law.
15.3 Operators and service providers must be required to escalate relevant suspected security compromises promptly in accordance with applicable legal and contractual obligations.
15.4 The responsible internal escalation roles, incident contacts and operational response procedure are to be documented in PrimaEdge's internal Security Compromise / Data Incident Response Procedure.
16.1 Subject to applicable law, a data subject may request access to personal information, request correction or deletion, object to qualifying processing, withdraw a consent previously given, and lodge a complaint with the Information Regulator.
16.2 A deletion request remains subject to lawful health-record, evidential, regulatory and other retention requirements.
16.3 Practical privacy / data-subject request channel: TO CONFIRM.
17.2 PrimaEdge maintains or will maintain internal governance instruments appropriate to its operating model, including a Data Retention Schedule, Security Compromise / Data Incident Response Procedure, Operator and Service Provider Register, Data Subject Rights Procedure, staff access matrix and auditable consent/withdrawal records.
17.3 Access, operator, retention, incident and Member-choice controls should be reviewed as the platform and service model develop.
18.1 PrimaEdge will assess material changes to the system or service that may affect privacy, confidentiality or security, including new categories of information, changed access roles, new operators or integrations, foreign storage or access, materially different reporting, or new research uses.
18.2 A change to this Statement or another contractual or policy document does not substitute for a fresh Member choice where applicable law requires consent for a materially different consent-dependent purpose.
18.3 This Statement should be reviewed when the underlying system or operating model changes materially and should remain subject to document version control.
This Statement should be read together with PrimaEdge's Privacy Notice, POPIA Consent Notice, Member/App Terms, Employer Services / Commercial Terms and PAIA Manual. Each document performs a distinct function, and this Statement does not override a more specific legal function performed by another document.