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 direct patient identifiers are in the system). Clinical values linked to a subject code remain special-category personal data. Both protections work at the server level, not the interface — so they cannot be bypassed by “peeking” at an API response or an export.

Blinding

Blinding is set by the field (ItemDef.blinded) and by the role. Only an unblinded role — a holder of data.unblinded.read in its scope (for example, an independent statistician or an unblinded pharmacist) — sees a blinded value. Everyone else gets a mask in every channel and has no “show” button: a blinded value cannot be revealed by accident.

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.

The unblinded role and emergency code break

• data.unblinded.read is assigned explicitly and with a reason — as a grant or a role (the “Unblinded Statistician” preset). The assignment and its revocation are recorded in the audit trail, which shows who was unblinded and when. Administrators do not get it automatically.
• The unblinded role sees values with no extra step. Every screen or download that showed it blinded values leaves one “Unblinded read” entry in the audit trail: who, where and which forms or records — without the values themselves.
• A blinded role can learn a specific subject’s treatment group only through an emergency code break — performed by the investigator, with a reason, confirmation, and a sponsor notification.

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 is always built with an explicitly chosen blinding profile: “blinded” (masked, the default) or “unblinded” — the latter requires the permission for unblinded data. The “mask by the launcher’s permissions” mode is gone: the blinding of every export is visible in the Exports journal row itself.
• 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 — a subject is addressed by a code; the “code ↔ person” table stays at the site.
• Pseudonymization is not anonymization: clinical values linked to the code are special-category personal data (health data, Art. 10 of Federal Law 152-FZ) while the re-identification key exists. Minimize the fields to what the protocol needs (Art. 5(5) 152-FZ): the system demography template asks for the year of birth, not the full date.
• Files and images are uploaded already de-identified: redacting direct identifiers on a source-document scan is the site’s step before upload, exactly as when handing a copy to a monitor.
• 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: localization is only a presentation, and the canonical data is stored in a neutral form. Staff names in the audit trail are personnel data, not participant data — they are what makes a record attributable.

How this relates to access

Blinding is ordinary access mechanics, not a separate “mode”:

• a field’s blinding is set in the design (ItemDef.blinded);
• only a holder of data.unblinded.read in the relevant scope sees the value;
• assigning and revoking that permission is audited;
• 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.

What’s next

Audit trailWhere permission assignments and emergency code breaks are recorded.

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.