Architecture

Medipal is delivered as one instance per organisation. An instance is made of a small number of parts that talk to each other over HTTPS.

                 ┌───────────────────────┐        ┌───────────────────────┐
                 │   Medipal web app     │        │   Medipal mobile app  │
                 │ clinicians & admins   │        │ patients (iOS/Android)│
                 └───────────┬───────────┘        └───────────┬───────────┘
                             │  embeds                        │  embeds
                 ┌───────────▼────────────────────────────────▼───────────┐
                 │            Questionnaire engine bundles (CDN)           │
                 └───────────┬────────────────────────────────┬───────────┘
                             │                                │
                 ┌───────────▼────────────────────────────────▼───────────┐
                 │                       Medipal API                       │
                 │  questionnaires · patients · schedules · submissions    │
                 │  roles & scopes · vault · workflows · events · analytics│
                 └──┬──────────────┬──────────────┬──────────────┬─────────┘
                    │              │              │              │
             ┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼─────┐
             │  Database  │ │  Plugins   │ │  Webhooks  │ │ EHR (FHIR) │
             └────────────┘ └────────────┘ └────────────┘ └────────────┘

The parts

Medipal web app. The browser application used by clinicians and administrators. It contains the questionnaire designer, patient and enrollment management, results, analytics, the workflow editor, the admin panel and the AI assistant. It talks only to the Medipal API.

Medipal mobile app. The patient application for iOS and Android. It is paired to an instance once, then downloads scheduled questionnaires, stores them encrypted on the device, lets the patient answer offline and synchronises answers when a connection is available. See Mobile App.

Medipal API. The server that owns all data and enforces all rules: authentication, roles and scopes, folder configuration, questionnaire revisions, scheduling, submissions, the vault, workflows, event delivery, analytics and EHR access. Everything the apps show comes from the API; nothing is decided in the browser or on the phone. Data is stored in a relational database.

Questionnaire engines. Rendering a questionnaire is not built into the apps. It is done by a self-contained engine bundle, published to a content delivery network and embedded by both apps. An engine combines the questionnaire core (question flow, validation, languages, scoring) with a set of question components. Organisations can build their own engines with custom components and pick which engine a questionnaire uses. See Questionnaire Engine.

Plugins. Server plugins are installed into an instance and expose actions that workflows can call, for example sending email or calling an external REST API. Frontend plugins add tabs and panels to the web app. See Plugins.

Workflows and events. Every meaningful change (a submission arrives, a patient is enrolled, a questionnaire is published) is recorded as an event. Workflows react to events with conditions, computations, delays, HTTP calls and plugin actions. Event subscriptions deliver the same events to external systems as signed webhooks. See Workflows and Webhooks & Subscriptions.

Clinical sources. An instance can be connected to one or more hospital systems through FHIR. Patients are linked to their records, and clinical data appears next to questionnaire results and in analytics. See Clinical Sources.

Analytics. Datasets, charts and dashboards are defined inside the web app and computed by the API from submissions and clinical data. See Analytics.

Schema-driven consistency

The data model and the API contract are defined once, in a single schema. The API, its request and response models, the database structure and the typed clients used by the web and mobile apps are all generated from that schema. A change to the model reaches every part of the platform in the same release, so the apps and the API never disagree about what a questionnaire, a patient or a submission looks like. The full API contract is available on every instance as an OpenAPI document; see API Access.

Folder tree and configuration

Questionnaires are organised in a folder tree. Configuration and permissions are attached to folders and inherited downwards: a setting made on a parent folder applies to every folder and questionnaire beneath it unless a closer folder overrides it. This is how one instance serves several departments or studies with different defaults. See Folders & Configuration.

Deployment

Each instance is deployed as a set of containers on Kubernetes using Helm charts, with images pulled from a private registry. Deploying partners provision one namespace per organisation and manage upgrades and configuration through a command-line tool. See Deploying an Instance. For a deeper look at the server side, see the API Server section; for the technologies used in each part, see the Technology Stack.