Glossary
The terms below are explained not in the abstract, but as X7 Insight uses them. Where the interface shows an English word, it is given in parentheses. Links lead to the sections where a term is covered in more detail.
| Term | What it is in X7 Insight |
|---|---|
| Amendment | A change to the study design after publication: edits are made in a new design version, which goes through review and publication. Some edits are safe (labels, ordering); others require subject migration and may invalidate signatures. |
| Tenant | The client organization (sponsor or CRO). The boundary of data isolation and of a separate audit chain. |
| Audit trail | An immutable log of all changes: who, when, before/after, why. Append-only, protected at the database level. See Audit trail. |
| Actor | Who performed an action in the audit: a user, a module, or the system. |
| Lock | A prohibition on changing data within a scope. A soft lock warns and holds back changes; a hard lock is a full prohibition. See status axes. |
| Design version (StudyVersion) | An immutable snapshot of the study design (protocol + amendments). Once published it no longer changes — the basis of reproducibility. See Study design. |
| Visit (Study Event) | A point in the schedule to which forms are attached. It may be scheduled, unscheduled, or common. A subject’s actual visit is a “visit instance.” |
| Grant (PermissionGrant) | A permission that has been issued: to whom, which one, in which scope, and for what time window. Expanded from assigned roles. |
| Completion | A field’s status axis: empty / entered / not done / unavailable. “Not done” is a deliberate state, not emptiness. |
| Query | A question about the data: a discrepancy, a clarification, a remark. It follows its own state machine: open → answered → closed. See Monitoring & cleaning. |
| Value (ItemData / datapoint) | A unit of clinical data — a single entered field for a subject. It carries independent status axes (completion, SDV, review, signature, lock, queries). |
| Inspection Readiness Packet | The Admin → Inspection section: in a single action it assembles a ZIP evidence package for a regulatory inspection (audit + chain verification, anchors, access, design). Always blinded. See Audit trail. |
| Casebook | The “visits × forms” matrix for a single subject — the working canvas for data entry. See Data entry. |
| Code list | A managed list of allowed values for a field. The code is canonical; its decode is localizable. |
| Medical review | A field’s status axis: not reviewed / reviewed / reviewed with a flag. The medical monitor’s workspace. |
| Version migration (subject.migrate_version) | The explicit transfer of subjects to a new design version according to a field-mapping plan. Data never migrates “on its own.” |
| Module | A pluggable capability on top of the core: coding, format exporters, RTSM, and so on. Enabled with the administrator’s consent. See Modules. |
| Blinding | A blinded field is shown as •••; the value is visible only with the permission to see unblinded data, and unblinding is audited. See Blinding and privacy. |
| Signature (electronic signature) | A legally significant Part 11 electronic signature over a snapshot of data: name, time, meaning. Editing the covered data invalidates it. See Electronic signatures. |
| Field (ItemDef) | A CRF field definition: type, code list, annotations, blinding flag, and whether SDV is required. A filled-in field for a subject is a “value” (ItemData). |
| Permission | An atomic “object.action” unit, for example data.update. See Permission catalog. |
| Principal | An access subject: a user, a module, or the system. Each module enablement has its own principal. |
| Reason for Change (RfC) | A mandatory reason when editing an already-saved value. Initial entry does not require a reason. See Data entry. |
| Separation of Duties (SoD) | A rule that blocks (block) or warns (warn) against a dangerous combination of permissions in one person — for example, “whoever entered the data does not verify it.” |
| Role | A named set of permissions assigned to a principal within a scope. Not a “job title” but a configurable set. See Roles & access. |
| Scope (ScopePath) | A permission’s hierarchical path: study → site → subject → form → field. A permission applies to the path and everything beneath it. |
| Subject | A study participant. Identified by a pseudonymous code — no personal names. Statuses form a configurable state machine. |
| Form / CRF (FormDef) | An electronic form for entering visit data. The fillable instance for a subject is a “form instance” (FormInstance) with an entry status. |
| Hash chain | A cryptographic chaining of audit records: any after-the-fact edit breaks the chain and is caught by verification. See Audit trail. |
| Site | A clinical site (clinic). StudySite is a site’s activation within a study; a closed site blocks the enrollment of new subjects. |
| Export | A reproducible snapshot of study data in regulatory formats. It can be as-of — reflecting the state at a given moment. Every download is audited. See Signatures, locks, export. |
Who’s who (roles and participants)
Section titled “Who’s who (roles and participants)”Roles in X7 Insight are configurable sets of permissions, not rigid job titles. Below are the familiar role names and what they usually do. See Roles & access.
| Role | What they usually do |
|---|---|
| Coordinator (CRC) | enrolls subjects, enters visit data, answers queries |
| Monitor (CRA) | verifies data against source (SDV), opens and closes queries |
| Investigator (PI) | signs data with an electronic signature |
| Data manager (DM) | runs data cleaning, locks the database, launches exports |
| Medical monitor (Medical Monitor) | performs medical review of safety data |
| Study Builder | assembles the design: forms, code lists, edit checks, visit schedule |
| Administrator (Admin) | manages the tenant’s access, roles, and modules |
| Inspector / auditor (Inspector) | views data and the audit trail in read-only mode |
Standards and acronyms
Section titled “Standards and acronyms”| Term | What it is in X7 Insight |
|---|---|
| ALCOA++ | A set of data-integrity principles (Attributable, Legible, Contemporaneous, Original, Accurate + Complete, Consistent, Enduring, Available, Traceable). Audit and export rely on them. |
| as-of | A “state as of a date” data snapshot: a reproducible reconstruction of how the data looked at a past moment. Used in exports. |
| CDISC ODM | A regulatory XML format for exchanging clinical data (Operational Data Model); it supports a change history (the AuditRecords block). An industry standard the data model is aligned to. |
| Dataset-JSON | A modern CDISC format for tabular clinical data (JSON). An industry standard for tabular export. |
| eConsent | A participant’s electronic informed consent. The consent signature records a specific version of the text and translation. |
| edit check | A declarative data-control rule applied at entry. Its action is either query (open a query) or block (prevent saving). |
| ePRO | Data entered by the participant themselves (electronic Patient-Reported Outcomes). The participant can enter but not edit saved responses. |
| go-live | Moving a study into production (“Active”): it opens real subject enrollment. Requires gates and a deliberate reason. |
| form instance (FormInstance) | A specific fillable instance of a form for a subject. Has a status: not started / in progress / complete. |
| MedDRA | A medical dictionary for coding adverse events. LLT (Lowest Level Term) is the lowest term level; PT (Preferred Term) is the preferred term to which an LLT rolls up. Used by medical-coding modules. |
| Outbox (transactional outbox) | A reliable event-delivery mechanism: an event is written into the same Postgres transaction as the change itself and delivered to subscribers (modules) by a background worker — only after the commit. It guarantees a notification never goes out before the change is committed, and is never lost. |
| Part 11 (21 CFR Part 11) | The FDA rule on electronic records and signatures. It defines the requirements for audit, signatures, and access control. See Electronic signatures. |
| PII (personal data) | Direct patient identifiers (name, address). Not stored in the EDC — a subject is identified by a pseudonymous code. See privacy. |
| RTSM / RTSM module | Randomization and Trial Supply Management. The transition of a subject to the “randomized” status is usually performed by this module. |
| SDV (Source Data Verification) | Reconciliation of entered data against source documents. A field’s status axis: not required / pending / verified. The monitor’s (CRA) workspace. See Monitoring. |
| SoA / Visit matrix (Schedule of Activities) | The study schedule: which visits there are and which forms are on each. Defined in the design. |
| SoD | See “Separation of Duties” above. |
| UAT (User Acceptance Testing) | A study status for a run on test data: test subjects do not appear in production exports. Precedes go-live. |
Status lifecycles and axesAll states and transitions in plain language.
Permission catalogWhat can be permitted and by what principles.
Audit trailThe immutable log and integrity verification.
What is X7 Insight EDCAn overview of the data journey from design to close-out.