> For the complete documentation index, see [llms.txt](https://docs.sygnal.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sygnal.network/concepts/privacy-and-data-minimisation.md).

# Privacy and data minimisation

How "clinical data stays at the edge" is enforced by the protocol and its implementation, not promised in a policy document.

Sygnal builds its privacy guarantees into the protocol and its reference implementation. They are not a policy promise added on top. (Where a reference component is still being built, the rules below are the requirements it must meet; see each component's status.) This page explains what reaches the network services, what never does, and how that boundary is enforced.

## What reaches the network services, and what never does

| Can reach the control plane                                                                          | Never does                                                                                                           |
| ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Event type: referral placed, accepted, completed                                                     | Diagnoses, except the condition code in a governed notifiable report                                                 |
| Timestamps and participant identifiers (platforms, not people)                                       | Clinical notes                                                                                                       |
| Coded reasons, such as a deviation reason code                                                       | Lab results or vital-sign readings                                                                                   |
| Aggregate counts for a stated period and coded area                                                  | Names or identifiers that unlock the record                                                                          |
| Hashed references: a pseudonymous subject reference, or a commitment to an artefact held at the edge | Free text about a patient                                                                                            |
| For notifiable conditions only, a limited set of fields with a legal basis                           | Anything that identifies an individual in a handoff both sides agree went as expected (it counts only in aggregates) |

The **peer-to-peer plane** is different. A handoff between two authorised parties carries the context the receiving side needs to act on. See [Two planes](/concepts/architecture.md#two-planes).

## What may travel peer to peer

Sygnal's position on patient information, by kind of interaction:

1. **Any Sygnal interaction that is not peer to peer never carries personal or clinical data about a patient.** This covers everything sent to or from the network services: deviations, reports, signals and policies. The one governed exception is [reporting of notifiable conditions](#the-exception-for-notifiable-conditions). It carries a bounded set of fields under a stated legal basis.
2. **Where a health information exchange exists, point to it.** A handoff should carry a pointer to the record held in the exchange, not the record itself.
3. **Coordination-specific information may travel peer to peer.** The handoff between the two parties may carry what makes the referral possible, such as the referral note, coded reason and urgency. Encrypting that payload to the receiver's registered key is **recommended**, on top of TLS (the standard encryption of the connection). It also protects the content in intermediaries, logs and queues. It is not mandated.
4. **Health records beyond referral-enabling information should be shared outside the Sygnal network**, over the health system's records layer.
5. **Networks should define their own policy** for these elements: what may travel peer to peer, whether payload encryption is required, and which records layer to point to.

## How it is enforced

**1. Content is excluded at the edge, before anything leaves.** The edge adapter turns an event (a referral, a visit, a completed task) into a coordination message that carries only metadata. Clinical detail is never packaged for the control plane, so there is nothing to strip out later.

**2. Trust runs on signatures, not disclosure.** Both sides of a handoff sign what they sent and received. Matching signatures show that both agree it happened, without either side handing a record to the network.

**3. Silence is the default.** While both sides agree, nothing that identifies an individual reaches the network services. Only a mismatch, an unexplained gap, an aggregate the policy permits, or a governed notifiable report ever leaves.

**4. What may leave is set by policy, field by field.** The reporting policy's `dataMinimization` is the single source of truth. Its allow-lists are JSONPath expressions that the **edge** evaluates against its own outgoing events. The receiver **must** refuse a report that carries anything outside the allow-list (`403`).

**5. Policies can only narrow.** When several policies apply, data minimisation always merges to the most restrictive result. See [the narrowing invariant](/concepts/policies.md#policies-can-only-narrow).

**6. The network never queries.** There is no search or filter API on the network services. The read APIs resolve by reference: `deviation/get` and `plan/get` return a single record, and `policy/get` returns the policies that apply to the requesting edge. Dashboards query the services' own stores, which hold only what was reported under policy.

## Aggregates

Aggregate reporting is the default and covers most needs. An aggregate `CoordinationEvent`:

* covers a stated **`period`** (an ISO 8601 interval) and a coded **`area`** (codes only, never free text or coordinates);
* carries **`metrics`** whose keys must be codes defined in the policy's `metricDefinitions`. An unknown code is refused;
* reports **counts, never rates**. Edges send numerator and denominator as two counts, so the network can add them up again across facilities and districts;
* has an `id` and a `revision`, so a late correction from an edge that was offline replaces the earlier figure instead of being double counted.

**Small cells.** No single field identifies anyone, but combinations can. "Measles, area X, week 32: 1 case" can point to one household in a small village. The policy's `minCellSize` (recommended: 5) tells the edge to suppress any value below the threshold, or roll it up to a coarser area or a longer period. The edge should also suppress a second value if someone could work out the hidden one by subtraction.

## The exception for notifiable conditions

For a named set of **notifiable conditions** (for example tuberculosis, measles or cholera), a policy can permit individual-level reporting. It is explicit and bounded:

* `appliesToConditions` names the conditions;
* `allowedFields` is a bounded allow-list of fields, set per health system as the minimum needed to triage and what notification law requires;
* `legalBasis` cites the mandate;
* a pseudonymous `subjectRef` may be included if the policy permits it.

This is the one place Sygnal may carry more than a hash. Governance draws this line on purpose, and keeps it minimal and auditable.

{% hint style="info" %}
**Direction of travel: notifiable reporting by reference.** One proposal, still open, is that a notifiable event would carry only metadata, the triage fields and a **reference**. The full record would stay at the edge. An authorised public-health participant would fetch it through a signed, role-checked read. This moves control from send time (what leaves) to access time (who reads it, and why). See [Open questions](/reference/open-questions.md).
{% endhint %}

## Two channels, both content-free

Operational telemetry (message counts, response times, ACK/NACK replies that confirm or reject receipt, and timeouts) travels separately from coordination events and **never** carries payload content. The reference adapter is designed to enforce this in three places: selective, header-only audit logging; an allow-list at the adapter's telemetry collector; and the same allow-list again at the network's collector. See [Reporting and signals](/concepts/reporting-and-signals.md#two-channels-coordination-events-and-network-telemetry).

## Identifiers

* `transactionId` and `messageId` must be random UUIDs, never derived from a patient or household identifier.
* Pseudonymous subject references need care. A plain hash of a small-space identifier, such as a phone number or a national ID, can be reversed by hashing every candidate. Linking records across programmes therefore calls for a **keyed** hash. The key is shared among edges and never held by the network services. The hashing scheme is an [open question](/reference/open-questions.md).

## Remaining risks

* **Re-identification from metadata patterns.** Even without identifiers, sequences of visits and timings could identify someone in a small population. `minCellSize`, coarse areas and aggregate-by-default reporting reduce this risk. They do not eliminate it.
* **Open extension fields.** Typed `*Attributes` extensions on some resources (not on `CoordinationEvent`) are open by design. Networks that define them should keep them coded and free of personal information.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sygnal.network/concepts/privacy-and-data-minimisation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.