This section explains how PII data behaves in OpenClinica 4—how it is stored, displayed, and protected—and how it interacts with form permissions and user roles.
What Makes PII Data Different
PII data includes personally identifiable information such as names, email addresses, and phone numbers.
It can be collected directly in the system UI (for example, when inviting a Participant to Participate) or within study forms, if those forms are designed to capture it.
When a study designer adds a field configured to use the external value (bind::oc:external) contactdata, that form automatically becomes a Contact Form.
For information about designing Contact Forms, refer to Designing Forms Including PII Data.
This designation ensures that any data collected in those fields is handled separately from clinical data and follows the stricter storage and access controls applied to contact information.
Forms can include both contact and non-PII data fields, but only fields using the contactdata external value are treated as PIIdata for storage and access purposes.
PII Data vs. Contact Form
PII data and Contact forms are related but distinct. The table below summarizes how they differ in purpose, behavior, and system treatment.
| Aspect | PII Data | Contact Form |
|---|---|---|
| Definition | Individual data fields that capture personally identifiable information (PII) such as Name, Email, or Phone Number. | A form that includes one or more fields configured with the external value contactdata. The system automatically tags it as a Contact Form. |
| Configuration | Defined at the field level by setting Use External Value = contactdata in Form Designer, or bind::oc:external = contactdata in the Form Template. | Defined automatically when a form contains at least one contactdata field. |
| Scope | Represents the item data—the specific pieces of participant information. | Represents the container—the study form that holds contactdata fields. |
| Storage & Security | Stored separately from clinical data and linked directly to the participant record; subject to masking and access restrictions. | Follows special access and visibility rules for any included contactdata fields. See How Contact Data is Displayed in Study Runner section below. |
| Coexistence with Non-Contact Fields | Can appear alongside non-contact fields within a form, but only contactdata fields follow PII data controls. | May contain both contact and clinical fields; only contactdata fields are treated as PII data. |
| Example | “Mobile Number” field marked as contactdata. | “Participant Update” form containing both Mobile Number (contactdata) and Visit Date (clinical) fields—automatically tagged as a Contact Form. |
PII Data vs. Clinical Data
PII data and clinical data serve different purposes in a study and are handled separately in OpenClinica.
| Category | Description | Examples | How It’s Stored |
|---|---|---|---|
| PII Data | Personally identifiable information (PII) used to identify or communicate with participants. | Name, Email, Phone Number, Address, Secondary ID | Stored separately from standard form data and linked directly to the participant record. |
| Clinical Data | Information collected as part of the clinical trial that describes participant health, trial activities, or outcomes. | Test Results, Vital Signs, Adverse Events, Concomitant Medications, Questionnaires | Stored in the main clinical data repository. |
For information on visibility of PII data, refer to the How Contact Data is Displayed in Study Runner section below.
For information on access control of PII data, refer to the How Access to Contact Data Works section below.
Example Scenarios
The following examples illustrate how OpenClinica distinguishes between contact and clinical data in different contexts:
- A CRC enters a participant’s email and mobile number directly in the Participant Invite screen. These fields are stored as PII data, visible only to authorized roles, masked in exports, and not passed to Reporting and Analytics.
- During a visit, the same participant’s vital signs and lab results are recorded in a form. These fields are stored as clinical data, included in the study datasets, and available to roles with appropriate form permissions.
- A study designer creates a “Participant Update” form containing both contact and clinical fields. Only the fields marked with contactdata are treated as PII data and follow its stricter storage and access rules.
Collecting PII Data on Forms
A study may choose to collect participant contact details entirely outside of forms or within specific forms designed for that purpose.
Forms can include both contact and non-PII data fields.
Only fields configured with the external value / bind::oc:external = contactdata are treated as PII data and stored separately from clinical form data.
For more information on how to design Contact Forms, refer to Designing Contact Data Forms.
Each piece of PII data only needs to be entered once. For example, if a participant’s first name is entered on the Participant Invite screen, it will automatically appear in any form that includes a corresponding First Name PII data field, without requiring the user to re-enter it.
When a form includes one or more contactdata fields:
- The form is automatically tagged as a Contact Form.
- By default, CRCs and Investigators can edit it, while other roles have no access.
- You can adjust these defaults by applying form-level permission tags in Study Designer. For more information on permission tags, refer to Permission Tags.
- This allows you to modify access for that form only, without changing broader role permissions.
- For information on access control of PII data, refer to How Access to Contact Data Works.
How PII Data Is Displayed in Study Runner
To protect participant privacy, PII data is visible only where appropriate and is masked or excluded in other views.
The table below summarizes where PII data may appear in the system as well as any exceptions or special considerations for each area.
| Area | Access | Notes |
|---|---|---|
| Participant Matrix (Single Event View) | ⚠️ CRC/ Investigator | Visible only to CRCs and Investigators. All other users will see the form status icon, but are unable to view / edit the form. |
| Participant Details Page (General Information section) | ⚠️ CRC/ Investigator | Certain fields (for example, Email, Mobile) may display based on study configuration for CRCs and Investigators only. |
| Participant Details Page (Visits Section) | ⚠️ CRC/ Investigator | Contact form cards are visible and forms are available for CRCs and Investigators only. |
| Queries Page / SDV Page | ❌ No | PII data cannot be queried or source data verified, and therefore is not present. However, if there are clinical data items on the form, they are visible for CRCs and Investigators. |
| PDF Casebooks | ❌ No | PII data is present in the form details but masked for privacy. |
| Clinical Data Extracts and ODM XML/JSON Casebooks | ❌ No | PII data is present in the audit details, but masked for privacy. |
| Clinical Data API | ❌ No | If audit data is included in the API response, the PII data is present but masked for privacy. |
| Participant Audit Log | ⚠️ CRC/ Investigator Only | Visible only to CRCs and Investigators in the participant section. Masked for all other users, regardless of form permissions. |
| Consent – PII Data | ⚠️ CRC/ Investigator Only | Visible only to CRCs and Investigators. |
| Consent – Attestation | ⚠️ CRC/ Investigator Only | PII data visible only to CRCs and Investigators. Masked for all other users with access. |
| Reporting and Analytics | ❌ No | PII Data is not passed to Reporting and Analytics. |
How Access to PII Data Works
Access to PII data is intentionally limited and controlled through a combination of role permissions and form-level tags.
For more information on Adjusting Access with Permission Tags, refer to Managing Form Access and Permissions.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article