What are modules

The X7 Insight core handles the universal concerns: subjects, forms, data, queries, signatures, locks, audit. Everything else — medical coding, format exporters, randomization, electronic subject diaries — is added by modules: packages shipped with the same release as the core, running on top of it without changing it.

For clinical staff this means the set of features in your study depends on which modules are enabled. This is managed by the tenant administrator under Admin → Modules.

The first module — the Assistant

The first platform module is here — Assistant (AI): an in-perimeter, context-aware AI helper (chat explanations, OCR form prefill, design generation from a protocol). It strictly follows the “suggests — the human decides” rule and has no clinical-data write path. Everything below about enabling applies to it too.

Delivered modules are extensions on top of the core: the validation scope and the qualification effort for each module are defined separately in your validation plan.

How modules are installed

A module is a package shipped in the same release as the platform core. It arrives as a managed, change-controlled release by the platform operator, never loaded at runtime. The tenant administrator does not upload modules; they only enable, configure and disable the delivered ones.

1. Operator's managed releasesync with delivery (manifest)
2. Module in the platform catalogenable
3. Service principal + grantscalls
4. Works through ModuleContext.sdk.*

A module's path: from a managed release to working strictly through the SDK.

From then on the module works only through ModuleContext.sdk.*: every such call passes a permission check (PBAC) and is audited with a module_id tag — so the module’s actions are always distinguishable in the trail.

How a module fits into the workflow

A module does not reach into the core directly. It subscribes to events (for example, “data saved”), keeps its own storage, and adds its own screens and panels in strictly designated places in the interface. That is why modules can be enabled and disabled independently, without breaking the main workflow.

In practice you encounter a module as:

• a panel on a form (for example, the coding panel beside the fields);
• a study navigation item (for example, “Coding”);
• an action or format (for example, an export in an additional format in the Export Console — if such a module has been delivered to you).

What exactly you see still depends on your permissions: even an enabled module shows its panels only to those who hold the corresponding permission.

Enablement and permissions

A module is enabled for the whole tenant — one enablement per module. There is no separate “capability consent”: the permission set of the module’s service principal is defined by the delivery manifest, and the administrator sees that same set on the module’s card.

• Module permissions — the module’s own permissions (mod.<id>.*) for its screens and data;
• Core grants — which core permissions the module receives for its service “user”, and why: each grant in the manifest comes with a human-readable reason (for example, “read verbatim values to build the coding queue”).

The grant set cannot be changed from the interface: a module release with a changed manifest goes through the same managed release, and the permission change is recorded in the audit log (module.grants_synced) when the platform is updated.

Which studies a module applies to is decided not by enablements but by people’s permissions: a module’s panel or navigation item is visible to those who hold the corresponding mod.<id>.* permission in that study’s scope. The same module can work in some of the tenant’s studies and not in others — precisely because people’s permissions differ.

Why permissions belong to people

An enabled module never widens anyone’s access: in the module’s screens you only see what you are permitted to see, and the module itself acts at the intersection of its grants and the current user’s permissions.

How to enable a module

1. Open Admin → Modules and select a module — its card opens: where it is enabled, module permissions and requested grants, settings; UI slots, events and entities are under “Technical details”.

2. Click Enable — there is one enablement per tenant.

3. If needed, set the module settings (for example, the dictionary version for coding).

4. Confirm — the module is enabled, and its panels and navigation items appear for users with the module permissions in their studies.

After enablement, the module’s settings and log are available on the same card. The log is an audit trail: the module’s sync with the delivery (including permission changes, module.grants_synced), its disappearance from the delivery (module.absent) and every enable/disable are recorded.

Disabling: the data stays

A module can be disabled at any time (with a reason). On disablement its grants are revoked, its event subscriptions stop, and its panels and navigation items disappear.

Module data is never deleted

Disabling a module does not delete the data it has accumulated — coding decisions, randomization records, results, and the rest remain in the system. If the module is later enabled again, its history is preserved. This follows from the platform’s general principle: data is never deleted silently.

What modules contain

The core stays thin and unchanged, while applied, domain features are moved into modules. Below are example categories, not a list of shipped modules: the exact set in your study is determined by which modules the platform operator has delivered and the administrator has enabled.

• Medical coding — assigning verbatim terms to controlled dictionaries (for example, MedDRA, WHODrug).
• Format exporters — exporting data to specialized industry formats on top of the core export.
• Randomization and supplies (RTSM) — dynamic schemes (minimisation) and drug supply; randomization by list and emergency code break are in the core — see Enrolling subjects.
• eConsent / ePRO — electronic consent and data entered by the participant themselves.
• Monitoring — advanced workspaces and data-cleaning metrics.
• Configuration testing — test cases for eCRF rules and a test report bound to the design fingerprint (the shipped eCRF configuration testing module).
• Laboratory data — reference ranges and L/H flags next to values (the shipped Laboratory reference ranges module).

What’s next

Assistant (AI)The first platform module: chat, form prefill, design generation.

Roles & accessHow grants and scope determine what is available to you.

Permission catalogModules' own permissions and what modules are never allowed.