> For the complete documentation index, see [llms.txt](https://docs.oomus.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.oomus.org/security/data-protection.md).

# Data protection

Oomus CampaignID is designed according to the principle of **data minimization** : only the information strictly necessary for the service to function is collected and processed.

***

## Categories of processed data

### Program data (organization)

| Data                | Description                           | Purpose                       |
| ------------------- | ------------------------------------- | ----------------------------- |
| Organization name   | Program or ministry name              | Account identification        |
| Email address       | Program manager contact               | Authentication, notifications |
| Pricing plan        | Subscribed plan, quotas               | Billing, access to features   |
| DHIS2 configuration | URL and credentials (encrypted)       | Enrollment synchronization    |
| Audit logs          | Actions performed (actor, action, IP) | Security, compliance          |

### Beneficiary identifiers

| Data                   | Description               | What is stored                                   |
| ---------------------- | ------------------------- | ------------------------------------------------ |
| MPI identifier         | Unique sovereign code     | Yes — this is the primary data                   |
| First name / Last name | Beneficiary name          | Yes — displayed on the card                      |
| Date of birth          | Beneficiary date of birth | Yes — used for MPI deduplication                 |
| Sex                    | Gender                    | Yes — used for MPI deduplication                 |
| Phone number           | Beneficiary contact       | Yes, if provided (for SMS/WhatsApp distribution) |
| District / Region      | Geographic area           | Yes — component of the MPI ID                    |
| DHIS2 UID              | External identifier       | Yes, if linked via DHIS2                         |

### Card codes

| Data             | Description            | Storage                                |
| ---------------- | ---------------------- | -------------------------------------- |
| Unique card code | Base36 card identifier | SHA-256 hashed in the offline registry |
| QR token         | SHA-256 opaque token   | Stored hashed only                     |
| Card status      | `valid` / `revoked`    | Yes                                    |
| Issue date       | Generation date        | Yes                                    |

***

## What is never stored

Oomus CampaignID never stores **never** :

* Complete medical records (diagnoses, treatments, prescriptions)
* Raw biometric data (fingerprints, iris, DNA)
* National identity card numbers (unless voluntarily provided as `external_id`)
* Personal financial data (bank account numbers)
* Real-time location data

***

## GDPR principles and minimization

Although Oomus CampaignID is not directly subject to the European GDPR (if deployed in countries outside the EU), we apply GDPR principles as a universal best practice:

| GDPR principle                    | Application in Oomus CampaignID                                      |
| --------------------------------- | -------------------------------------------------------------------- |
| **Minimization**                  | Only the data necessary for issuing and verifying cards is collected |
| **Purpose limitation**            | Beneficiary data is used only for card generation and distribution   |
| **Accuracy**                      | Data correction interface via the MPI registry                       |
| **Storage limitation**            | Retention period configurable by program                             |
| **Integrity and confidentiality** | AES-256-GCM encryption, HTTPS, RBAC, audit trail                     |
| **Accountability**                | Complete audit trail, approval workflows                             |

***

## Sensitive data safeguard — 7 categories

Before any export to analytics or ML pipelines, Oomus CampaignID applies an **automatic safeguard for sensitive data**. DHIS2 attributes belonging to the following 7 categories are **automatically excluded** from these processing flows:

| Category          | Examples of affected attributes                        |
| ----------------- | ------------------------------------------------------ |
| **HIV/AIDS**      | HIV serostatus, viral load, CD4, ARVs                  |
| **STI**           | Syphilis, gonorrhea, chlamydia, STI results            |
| **Tuberculosis**  | TB status, positive smear, DOT treatment, MDR-TB       |
| **Mental health** | Psychiatric diagnoses, psychotropic medications        |
| **Serological**   | Sensitive serological test results (beyond HIV/STI)    |
| **Biometric**     | Fingerprints, iris, facial scans, DNA                  |
| **Financial**     | Declared income, socioeconomic status, health payments |

These attributes remain **present and encrypted in the database** for the legitimate needs of the program. They are only excluded from:

* Analytical CSV exports
* Machine learning pipelines
* Debug logs
* Analytics API
* Shared dashboards

### QR code and privacy

The QR code printed on the card contains an **opaque token derived by SHA-256** — and not the MPI identifier or the beneficiary's name. This design ensures that:

* Scanning the card exposes no personal information
* A malicious actor collecting QR data cannot do anything with it
* Verification reveals only "valid / invalid", not identity

***

## Data retention

| Data              | Default duration                          | Configurable      |
| ----------------- | ----------------------------------------- | ----------------- |
| MPI identities    | Program duration + 5 years                | Yes (per program) |
| Card codes        | Campaign duration + 2 years               | Yes               |
| Audit logs        | 5 years                                   | No (compliance)   |
| Distribution logs | 1 year                                    | Yes               |
| PDF/ZIP artifacts | 6 months                                  | Yes               |
| Session tokens    | Token lifetime (short-lived / long-lived) | No                |

***

## Beneficiary rights

Although beneficiaries do not interact directly with the Oomus API, their rights can be exercised through the responsible health program:

| Right             | Mechanism                                                        |
| ----------------- | ---------------------------------------------------------------- |
| **Access**        | The program manager can export a beneficiary's data upon request |
| **Rectification** | The MPI registry can be updated via `PATCH /mpi/{mpi_id}`        |
| **Deletion**      | MPI identity deactivation possible (contact support)             |
| **Objection**     | Card revocation possible from the campaign interface             |

***

## Sovereign hosting option

For programs requiring data to remain within the national territory:

* **Sovereign hosting** : dedicated deployment on the program's national or regional infrastructure
* **Complete isolation** : the data never leaves the country
* **Local regulatory compliance** : adapted to national health data protection regulations

The sovereign hosting option is available with the Sovereign Enterprise plan.

***

## Next steps

* [Legal compliance](/compliance/legal-compliance.md)
* [Security overview](/security/overview.md)
* [Cryptographic guarantees](/security/cryptographic-guarantees.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.oomus.org/security/data-protection.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
