Reference
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. |
| Certified copy | A copy whose fidelity and completeness are demonstrated by the very process that creates it: in X7 Insight the server builds such copies — PDF/A with a SHA-256 checksum in the exports journal and the audit, not the browser’s print dialog. See Documents and certified copies. |
| Completion | A field’s status axis: empty / entered / not done / unavailable. “Not done” is a deliberate state, not an empty value. |
| 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 study Exports → Inspection packet tab: in a single action it assembles a ZIP evidence package for a regulatory inspection (audit + chain verification, anchors, access, design). Always blinded. See Inspection packet. |
| 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. |
| Site data copy | A certified ZIP package of one site’s data — casebooks, the site’s audit trail, queries, signatures and tabular datasets. Built at any moment from the closeout wizard’s “Site data copies” step (EMA 2023 §6.6). See Documents and certified copies. |
| 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. A package shipped with the same release as the core; enabled by the administrator per tenant, study applicability follows people’s permissions. 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) | An electronic signature over a snapshot of data, designed for the requirements of Part 11: 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 enabled module has its own service 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 export of study data — the core snapshot (JSON), CDISC ODM 1.3.2 or the CDISC tabular datasets. It can be as-of — reflecting the state at a given moment. Every download is audited. See Data export and closeout packages. |
Who’s who (roles and participants)
Section titled “Who’s who (roles and participants)”The familiar role names — coordinator (CRC), monitor (CRA), investigator (PI), data manager, medical monitor, Study Builder, administrator, inspector/auditor — and what each usually does are collected in a table in Roles & access.
Standards and acronyms
Section titled “Standards and acronyms”| Term | What it is in X7 Insight |
|---|---|
| aCRF (annotated CRF) | The annotated CRF: a form blank annotated with variables — OID, type, code list, unit, conditions and checks at every field. Built by the server from the design version (PDF). See Study design. |
| 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 | The open XML exchange standard for clinical research data (Operational Data Model), version 1.3.2. Exported as a snapshot or in Transactional mode — with the audit trail; an exchange standard, not SDTM. See Data export. |
| Dataset-JSON | A modern CDISC format for tabular clinical data (JSON). An industry standard for tabular export. |
| Define-XML | The CDISC metadata standard for tabular datasets: describes variables, code lists and methods — in X7 Insight it describes the Dataset-JSON/CSV/XLSX/XPT datasets of an export (version 2.1). |
| 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. |
| PDF/A | The PDF profile for long-term preservation (ISO 19005): the document looks the same years later, regardless of software. All X7 Insight print documents are PDF/A; the casebook is PDF/A-3 with an embedded machine-readable source. |
| PDF/UA | The PDF accessibility profile (ISO 14289): structure tags, language and reading order for screen readers. X7 Insight’s server-built PDFs carry it together with PDF/A. |
| PII (personal data) | Direct subject identifiers (name, address) are not stored in the EDC: a subject is a pseudonymous code, source files are uploaded de-identified. Clinical data under the code is still special-category personal data (152-FZ). See privacy. |
| RTSM / RTSM module | Randomization and Trial Supply Management. List randomization and emergency unblinding are in the core; an RTSM module is for dynamic schemes and drug supply. |
| SAS XPT (XPT) | The SAS v5 transport format for tabular data — read by statistics packages without SAS. One of the CDISC tabular dataset formats in an export. |
| 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.