Appearance

Core Concepts ​

The terms below appear throughout the documentation. Each links to the guide page that explains it in depth.

Instance and tenant ​

A Medipal instance is one deployment serving one organisation. It has its own database, users, patients and configuration. Applications identify the instance and the organisation (tenant) they belong to, and the API keeps data strictly within that boundary. See Deploying an Instance.

Folders and configuration inheritance ​

Questionnaires live in a folder tree. A folder carries configuration (defaults for questionnaires, engine selection, delivery options and more) and permissions. Both flow downwards: a questionnaire's effective configuration is the instance defaults, overlaid by every folder from the root down to its own folder, overlaid by the questionnaire's own settings. The closest level wins. See Folders & Configuration.

Questionnaires and revisions ​

A questionnaire is a structured set of sections and questions with logic, variables and scoring. Every edit creates a revision, so the history of a questionnaire is always available. Patients only ever receive published revisions; drafts can be previewed and simulated safely. A questionnaire can be forked to start a new one from an existing design. See Designing Questionnaires and Versions & Publishing.

Questionnaire engines ​

An engine is the versioned bundle that renders a questionnaire in the web and mobile apps. It combines the questionnaire core (question flow, validation, languages, scoring) with a set of question components. An instance can host several engines, and a folder or questionnaire selects which one to use. Developers can build their own engines with custom components. See Questionnaire Engine.

Enrollments, schedules and access windows ​

An enrollment connects a patient to a questionnaire. A schedule decides when the patient should answer: once, on fixed dates, or on a recurring pattern with an optional end. Each occurrence is a slot; an access window defines how long before and after the planned time the slot can be answered. See Scheduling & Enrollments.

Patients and devices ​

A patient is a person who answers questionnaires. Patients do not have passwords; they pair the mobile app with the instance through a device registration that clinicians initiate from the web app. A patient can have several devices, and devices can be revoked. See Patients & Devices.

Submissions ​

A submission is one completed questionnaire: the answers, the computed variables and scores, the revision that was answered and when. Submissions are the raw material for results, workflows and analytics. See Submissions & Results.

Anonymous questionnaires ​

An anonymous link publishes a questionnaire to people who are not registered patients, for public surveys or screening. Responses are collected without identifying the respondent. See Anonymous Questionnaires.

A consent document is a versioned text that patients must accept before taking part. Documents are translated per language and shown when a patient pairs a device or opens an anonymous questionnaire. See Consent Documents.

Clinical sources ​

A clinical source is a connection to a hospital system, typically a FHIR server. Once configured, patients can be linked to their records and clinical observations appear alongside questionnaire results. See Clinical Sources.

Roles and scopes ​

Access is controlled by scopes, small permissions such as "read questionnaires" or "manage users". A role is a named set of scopes assigned to users. Built-in roles cover administrators, clinical providers and integrations; custom roles can be defined. See Users, Roles & Scopes.

API keys ​

An API key lets an external system call the Medipal API with a fixed set of scopes and an optional expiry. Keys are shown once when created. See API Keys.

Vault ​

The vault stores secrets such as passwords, tokens and certificates in encrypted form. Other features (plugins, clinical sources, workflows) refer to a vault entry by name instead of holding the secret themselves. See Vault.

Workflows ​

A workflow is an automation that starts when an event happens and runs a graph of steps: conditions, computations, delays, HTTP requests, data mapping and plugin actions. Workflows can be simulated before they are enabled, and every run is recorded. See Workflows.

Events, subscriptions and webhooks ​

Every significant change produces an event. An event subscription delivers matching events to a webhook endpoint outside Medipal, signed so the receiver can verify them and retried if the endpoint is unavailable. See Webhooks & Subscriptions.

Plugins ​

A server plugin extends the API with actions that workflows can call and connectors to external services. A plugin is installed once and configured per plugin instance, so the same plugin can be used with different settings. A frontend plugin adds screens to the web app. See Plugins.

Analytics ​

A dataset selects submissions and clinical data; a chart visualises a dataset; a dashboard arranges charts with shared filters. Presets exist for common clinical instruments. See Analytics.