Blinding and privacy

X7 Insight protects two different things: the study’s blinding integrity (so that access to treatment codes does not “leak” through the data) and participant privacy (so that no patient personal data is in the system). Both protections work at the server level, not the interface — so they cannot be bypassed by “peeking” at an API response or an export.

0:000:00

A blinded field stays masked — only an explicit, audited reveal shows it

Blinding

Blinding is a separate axis: a specific field is marked as blinded (ItemDef.blinded), and on an ordinary read the server returns a mask instead of the value — to everyone, including holders of the permission for unblinded data (data.unblinded.read). That permission does not show the value itself: it only allows an explicit reveal, and every such gesture is audited.

Masking values

• A blinded field is shown as ••• — of fixed width. The mask’s length does not depend on the value, so it cannot reveal whether the value is “long” or “short”.
• Masking is done by the server during serialization, not by the browser. A role without clearance will not receive the value on a form, in the API, or in an export — there is nothing to hide, because the value is simply not transmitted.
• In the audit trail, blinded values in the “Before / After” columns are also masked for those without clearance.

Why the mask has a fixed width

Even the length of a value can betray the treatment code (for example, “2 mg” vs. “placebo”). That is why the mask is always the same width — it conveys only the fact that “there is a blinded value here”, and nothing more.

Unblinding (reveal) — only through an explicit, audited action

1. Blinded field
   • POST …/reveal — explicit gestureValue shown · audit data.unblinded_read
   ordinary read (GET)
2. Mask ••• — always

An ordinary read always masks — even for a data.unblinded.read holder; only an explicit gesture reveals, and it is audited.

A user with the data.unblinded.read permission can see the value through an explicit Show command. This is a privileged action:

• An unblinded read is recorded in the audit trail — who opened which field and when. This is one of the few audited kinds of read (ordinary reads are not logged).
• An emergency unblind requires a reason.
• The interface honestly warns: “Unblinded reading is recorded in the audit trail”.

Do not quote a blinded value in a query

The query text is not masked. If a field is blinded, do not copy its value into the query text — otherwise you will reveal the code to those who should not see it. The interface warns about this when you open a query on a blinded field.

Blinding in exports and packages

• An export masks blinded values by the permissions of whoever launches it: without the permission for unblinded data, the snapshot comes out masked. At launch you explicitly choose the “blinded — masked” mode (the default) or “unblinded” (which requires the permission).
• The inspection packet is always blinded: it never unblinds, regardless of the launcher’s permissions. The final package is blinded by default; an unblinded variant is possible under dual control: the data.unblinded.read permission is required from both the person who starts it and the person who downloads it.

An amendment can change blinding

Marking a field as blinded is part of the design. A change to blinding is recorded as a change to the design version (in the amendment history — “blinding changed”) and goes through the same review-and-publication path as any other design edit.

Privacy: pseudonymous subject codes

X7 Insight is a system for collecting clinical data, not a medical chart. A participant is identified by a pseudonymous subject code, not by name.

• The EDC does not store names, addresses, or direct patient identifiers. Personal data stays in the site’s source documentation (and, where needed, in a separate identity system), not in the EDC.
• A subject is a code (for example, an identifier within a site and study) plus clinical data and a status. Such a pseudonymous code makes it possible to maintain a participant’s data without revealing who they are.
• The data and the audit trail are language-independent and contain no PII: localization is only a presentation, and the canonical data is stored in a neutral form.

What this gives you in practice

The coordinator works with the subject code; the monitor source-verifies the data against that same code; the export carries the code, not the name. The “code ↔ real person” link stays at the site — outside the EDC.

How this relates to access

Blinding is not a role or a separate “mode”. It is ordinary access mechanics:

• a field’s blinding is set in the design (ItemDef.blinded);
• an ordinary read masks the value always; the data.unblinded.read permission in the relevant scope only grants the ability to perform an explicit reveal;
• the fact of an unblinded read is audited (data.unblinded_read);
• platform events filter their payload by the subscriber’s permissions, so that a blinded value does not “leak” through a notification to a module.

For more on permissions and scopes, see the Permissions catalog.

Audit trailWhere unblinded reads are recorded and how to verify the journal.

Permissions catalogdata.unblinded.read, scope, and the deny-wins principle.

GlossaryBlinding, subject, scope, PII — in plain terms.

Monitoring & cleaningHow to work with queries on blinded fields without revealing the value.