SureDox — PII Determination Framework

Purpose

This document provides a repeatable, legally grounded framework for determining what constitutes Personal Information (PI) on each document type SureDox processes. It serves as the authoritative reference when building ground truth files for regression testing.

Authority hierarchy:

1. POPIA Section 1 (definitions) and Section 26 (special PI) — primary
2. HIPAA §164.514(b) Safe Harbor — consulted for health data where POPIA is silent
3. UK ICO Anonymisation Guidance (March 2025) — consulted for the "motivated intruder" / "reasonably foreseeable" test
4. GDPR Article 4 — consulted for genetic data definition where POPIA is silent

Why foreign guidance is appropriate: POPIA contains no specific de-identification provisions beyond the definition in Section 1 and the exclusion in Section 6. South African legal scholars explicitly recommend consulting HIPAA §164.514(b) and the UK ICO code of practice where POPIA is silent (Swales, 2021, South African Journal of Science). The Information Regulator has not published de-identification guidance as of February 2026.

---

Part 1: Universal Rules (All Document Types)

These rules apply regardless of document category.

1.1 The POPIA Test

For any data item on any document, ask:

Is this information "relating to an identifiable, living, natural person" (or, where applicable, an identifiable, existing juristic person)? — POPIA Section 1

If YES → it is PI. The next question is: PI of whom?

1.2 Data Subject Identification

Every detection must identify the data subject — the person whose PI it is:

1.3 The De-identification Purpose Test

SureDox redacts documents for de-identification under POPIA Section 14(4). The purpose is to remove information that identifies the data subject. Therefore:

If an item is PI of someone OTHER than the data subject, it only needs redaction if it could be used as a re-identification pathway back to the data subject via a "reasonably foreseeable method" (POPIA Section 1 definition of "de-identify").

1.4 Universal PI Categories (Section 1)

These are always PI when they relate to an identifiable person:

1.5 Universal Non-PI Categories

These are NEVER PI regardless of document type:

1.6 The POPIA Basis Requirement

Every item in a ground truth expected_detections array must cite a specific POPIA section. If no section can be cited, the item does not belong in detections.

---

Part 2: Document Type Definitions

Document types SureDox supports:

---

Part 3: Per-Domain PII Guidelines

3.1 Legal Agreements (legal_agreement)

Data subjects: The contracting parties (natural persons as signatories, juristic persons as entities).

What IS PI (detect):

What is NOT PI (do not detect):

Borderline cases:

---

3.2 Medical / Health Documents (medical_health)

Data subject: The patient.

Special considerations: POPIA Section 26 classifies health data and genetic data as special personal information requiring heightened protection. HIPAA §164.514(b) Safe Harbor provides the most detailed guidance on which items must be removed for health data de-identification. South African scholars recommend consulting it where POPIA is silent.

What IS PI (detect):

What is NOT PI (do not detect):

Decision tree for health documents:

Is this about the PATIENT specifically?
├── YES: Is it a name, ID, date, demographic, diagnosis, or genetic finding?
│   ├── YES → DETECT as primary PI (cite POPIA section)
│   └── NO → Evaluate: does it narrow re-identification via "reasonably foreseeable method"?
│       ├── YES → DETECT
│       └── NO → DO NOT DETECT
└── NO: Is it about the INSTITUTION (lab, hospital)?
    ├── YES → DO NOT DETECT (institutional letterhead, not patient PI)
    └── NO: Is it about a PROFESSIONAL (doctor, lab scientist)?
        ├── YES → PI of that person under Section 1(h)
        │   └── Could it create a re-identification pathway to the patient?
        │       ├── HIGH RISK (specialist with few patients) → DETECT at reduced confidence
        │       └── LOW RISK (signs hundreds of reports) → DETECT at 0.50, secondary
        └── NO: Is it METHODOLOGY or GENERAL KNOWLEDGE?
            └── YES → DO NOT DETECT

---

3.3 Financial Documents (financial)

Data subject: The account holder / taxpayer / payee.

What IS PI (detect):

What is NOT PI (do not detect):

Borderline cases:

---

3.4 HR / Employment Documents (hr_employment)

Data subject: The employee or candidate.

What IS PI (detect):

What is NOT PI (do not detect):

---

3.5 Identity Documents (identity_document)

Data subject: The document holder.

Special considerations: Almost everything on an ID document is PI by design. The entire purpose of the document is identification. De-identification of an ID document essentially means redacting nearly all content.

What IS PI (detect):

What is NOT PI (do not detect):

---

3.6 General Documents (general)

Data subject: Varies — must be determined from context.

For documents that don't fit the above categories (letters, emails, mixed correspondence), apply the universal rules from Part 1:

1. Identify who the data subject is
2. Apply the POPIA Section 1 test to each potential PI item
3. Check whether the item is information "relating to" the data subject
4. Cite the specific POPIA section
5. Classify as primary or secondary relevance

---

Part 4: Ground Truth File Construction Process

Step-by-step for each new document:

1. Classify the document type using the categories in Part 2
2. Identify the data subject(s) — who is this document about?
3. Read the domain guidelines in Part 3 for that document type
4. For each item on the document, apply the decision:
   • Is it information relating to an identifiable person? → Which POPIA section?
   • Is it PI of the data subject (primary) or someone else (secondary)?
   • Is it institutional/public information? → Non-detection
   • Is it methodology/template/structural? → Non-detection
5. Build the JSON with every detection citing popia_basis and data_subject_relevance
6. Build the non-detections list — critical for regression testing. Over-redaction is as bad as under-detection
7. Build context classifications — items that require domain-specific context to classify correctly
8. Run against the regression suite — new ground truth must not conflict with existing ones

Ground truth JSON structure:

{
  "document": "filename.pdf",
  "document_category": "medical_health",
  "compliance_standard": "strict_popia",
  "total_pages": 6,
  "data_subject": "Patient (natural person)",
  "expected_detections": [
    {
      "value": "DOE, JOHN",
      "category": "NAMES",
      "context": "person_specific",
      "popia_basis": "Section 1(h) — 'the name of the person'",
      "data_subject_relevance": "primary",
      "confidence": 0.95,
      "pages": [1, 2, 3, 4, 5, 6],
      "notes": "Patient name — appears on every page header"
    }
  ],
  "expected_non_detections": [
    {
      "value": "LABORATORY FOR MOLECULAR MEDICINE",
      "reason": "institutional_letterhead — Testing laboratory name on standardised report header. Not PI of the patient. HIPAA Safe Harbor does not require removal of covered entity name."
    }
  ],
  "expected_context_classifications": [
    {
      "value": "c.244G>A",
      "expected_context": "patient_finding",
      "notes": "Patient's pathogenic variant — Section 26 genetic data"
    }
  ],
  "key_test_areas": [
    "Description of what the regression test should specifically validate"
  ]
}

---

Part 5: Foreign Guidance Quick Reference

HIPAA §164.514(b) Safe Harbor — 18 Identifiers

Scope: Identifiers of "the individual or of relatives, employers, or household members of the individual." NOT the healthcare provider/institution.

Key exclusions relevant to SureDox:

• Physician/workforce/vendor names do NOT need removal (HHS FAQ 3.8)
• Covered entity's own name, address, phone do NOT need removal
• The 18 identifiers are: names, geographic data smaller than state, dates (except year), phone, fax, email, SSN, MRN, health plan number, account numbers, certificate/licence numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number/characteristic/code

UK ICO Anonymisation Guidance (March 2025)

Key concept: "Motivated intruder" test — would a reasonably motivated person, without special knowledge, be able to re-identify a data subject from the remaining information?

Relevance to SureDox: Supports context-dependent assessment. The same item (e.g., a physician name) might or might not enable re-identification depending on how specialised the physician is.

POPIA's "Reasonably Foreseeable Method" Standard

POPIA Section 1 defines de-identification as deleting information that "can be used or manipulated by a reasonably foreseeable method to identify the data subject."

Interpretation (per Thaldar, PMC 2023): The identifiability of data subjects must be determined based on specific context. This aligns with the UK ICO's "reasonably likely" test and supports the view that institutional details on medical reports are not patient identifiers.

---

Part 6: Document Type Priority Roadmap

Current state (February 2026):

Priority order for next ground truths:

1. Financial — highest demand from compliance officers, clear PI patterns, tests merchant/institutional handling
2. HR/employment — common use case, tests employment equity data (Section 26 special PI)
3. Identity document — straightforward (almost everything is PI) but tests image-based/DocuPipe path
4. General — catch-all, lowest priority, most variable

For each new document:

1. Source a test document (real preferred, synthetic acceptable)
2. Apply Part 3 guidelines to classify every item
3. Build ground truth JSON following Part 4 structure
4. Run regression suite — must pass ALL existing ground truths
5. Add domain-specific classification prompt (implementation plan Steps 8-10)

---

Changelog