Understanding Contact Data

Modified on Thu, 8 Jan at 12:50 PM

Understanding Contact Data

This section explains how contact data behaves in OpenClinica 4—how it is stored, displayed, and protected—and how it interacts with form permissions and user roles.

What Makes Contact Data Different

Contact 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 Contact Data Forms.

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-contact data fields, but only fields using the contactdata external value are treated as contact data for storage and access purposes.

Contact Data vs. Contact Form

Contact data and Contact forms are related but distinct. The table below summarizes how they differ in purpose, behavior, and system treatment.

Aspect	Contact 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 contact data controls.	May contain both contact and clinical fields; only contactdata fields are treated as contact 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.

Contact Data vs. Clinical Data

Contact data and clinical data serve different purposes in a study and are handled separately in OpenClinica.

Category	Description	Examples	How It’s Stored
Contact 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 contact data, refer to the How Contact Data is Displayed in Study Runner section below.

For information on access control of contact 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 contact data, visible only to authorized roles, masked in exports, and not passed to Insight.
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 contact data and follow its stricter storage and access rules.

Collecting Contact 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-contact data fields.
Only fields configured with the external value / bind::oc:external = contactdata are treated as contact 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 contact 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 contact 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 contact data, refer to How Access to Contact Data Works.

How Contact Data Is Displayed in Study Runner

To protect participant privacy, contact data is visible only where appropriate and is masked or excluded in other views.

The table below summarizes where contact 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	Contact 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	Contact data is present in the form details but masked for privacy.
Clinical Data Extracts and ODM XML/JSON Casebooks	❌ No	Contact 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 contact 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 – Contact Data	⚠️ CRC/ Investigator Only	Visible only to CRCs and Investigators.
Consent – Attestation	⚠️ CRC/ Investigator Only	Contact data visible only to CRCs and Investigators. Masked for all other users with access.
Insight	❌ No	Contact Data is not passed to Insight.

How Access to Contact Data Works

Access to contact 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.