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, patient e-diaries — is added by modules: pluggable capabilities that run on top of the core 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 and capability consent applies to it too.

How modules are installed

A module is installed as a managed, change-controlled release by the platform operator, never loaded at runtime: manifest → capability negotiation → SDK. The tenant administrator does not upload modules; they only enable, configure and disable already-registered ones.

1. Operator's managed releaseregister (manifest)
2. Capabilities negotiatedenable
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) on behalf of the module’s service principal and is audited with a module_id tag — which is why “module X in study A” is always distinguishable in the trail from the same module in another study.

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 ODM-XML export in the Export Console).

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

Capability consent

The key idea behind enabling a module is informed consent. A module does not gain access silently: the administrator sees and confirms every capability and every grant the module requests.

The Capability consent dialog shows two things:

• Required capabilities — which core capabilities the module needs (event subscriptions, its own storage, its own screens, background jobs, and so on);
• Requested core grants — which permissions the module asks for on behalf of its service “user”, and why (each grant comes with a human-readable reason: for example, “read verbatim values to build the coding queue”).

The administrator confirms each item with a checkbox; the module can be enabled only after all of them are agreed to. The administrator may narrow the scope of any grant, but never widen it.

Why consent is per item

This is the only way the administrator truly controls what a module can access. There is no “install with all permissions”: every capability and every grant is shown with a “why” explanation and confirmed separately.

Per-study enablement

A module is enabled for the whole tenant or for a specific study. Each enablement has its own separate service principal that receives the agreed permissions. As a result, the same module can behave differently across studies (its own settings, its own scope), and the audit trail distinguishes “module X in study A” from “module X in study B”.

1. Open Admin → Modules and select a module — its card opens with the manifest: capabilities, module permissions, requested grants, events, UI contributions, and settings.

2. Click Enable, then choose a study (or the whole tenant).

3. In the consent dialog, confirm every capability and every grant.

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

5. Confirm — the module is enabled, and its panels and navigation items appear for users with the required permissions.

After enablement, the module’s settings and log are available on the same card. The log is an audit trail: the module’s registration 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 available to the new enablement. This follows from the platform’s general principle: data is never deleted silently.

Note

Registering new modules (and updating their versions) is done by the platform operator through a managed release — this is part of GxP change control. The tenant administrator does not upload modules; they only enable, configure, and disable ones that are already registered.

What lives in modules

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 registered 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) — assigning subjects to arms and tracking drug supply.
• eConsent / ePRO — electronic consent and data entered by the participant themselves.
• Monitoring — advanced workspaces and data-cleaning metrics.

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