Appearance
Technology Stack
Medipal is built from a small number of well-known open technologies. This page lists what each part of the platform is built with and what that technology is used for, so that developers and IT teams can judge how it fits their environment.
API server
| Technology | Used for |
|---|---|
| Python 3.12 | Runtime for the API server and its command line interface. |
| FastAPI | HTTP framework: routing, request validation and the generated OpenAPI document. |
| Pydantic | Request and response models, generated from the platform schema. |
| SQLAlchemy 2 | Object-relational mapping over PostgreSQL; the model classes are generated from the platform schema. |
| Alembic | Versioned database migrations, applied automatically before an upgraded server starts serving. |
| PostgreSQL 15 | The only database. Structured questionnaire definitions and answers are stored as JSONB, so they can be queried and indexed in place. |
| APScheduler | Background jobs: event delivery, webhook retries, housekeeping, directory synchronisation and heartbeats. |
| CloudEvents-style event envelope | Every domain change is recorded as an event with a stable envelope, consumed by workflows, subscriptions and webhooks. |
| JSON Logic | Portable rule language used for workflow conditions and data resolution. |
| JSON Schema and OpenAPI | The single source of the data model and API contract. |
| JSON Web Tokens, TOTP, bcrypt | Session tokens, multi-factor authentication and password storage. |
Web app
| Technology | Used for |
|---|---|
| Nuxt 4 / Vue 3, TypeScript | The administrator and clinician application, rendered in the browser. |
| Nuxt UI and Tailwind CSS | The component library and styling system shared with the questionnaire engines. |
| Pinia | Client-side state. |
| JSON Forms | Schema-driven forms for plugin configuration, engine options and question settings. |
| Interactive charting library | Analytics charts and dashboards. |
| Node-based graph editor | The visual workflow editor. |
| Full-featured calendar component | Scheduling and the per-patient calendar. |
| Microsoft Authentication Library | Sign in with Microsoft Entra ID. |
| Sentry | Error reporting from the browser. |
| Vercel AI SDK | The AI assistant conversation layer (the provider is configured per instance). |
Mobile app
| Technology | Used for |
|---|---|
| Nuxt / Vue 3 with Capacitor | One codebase for iOS and Android, packaged as native apps. |
| Encrypted SQLite | Offline storage of questionnaires, schedules and unsent answers. |
| Native local notifications and background runner | Reminders and background synchronisation. |
| Over-the-air update plugin | Delivery of updated questionnaire engines and app content without a store release. |
Questionnaire engine
| Technology | Used for |
|---|---|
| Vue 3 single-file components | Question components (renderers) written by Medipal or by third parties. |
| Shared UI library inside the core | The same Nuxt UI components as the web app, exposed to renderers so every engine looks and behaves the same. |
| Single-file HTML bundles | An engine is one self-contained file, versioned and published to a content delivery network. |
Schema and code generation
The data model and the API contract live in one YAML/JSON Schema source. A generation pipeline produces the Pydantic request and response models, the SQLAlchemy models, the OpenAPI document and the typed TypeScript clients used by the web and mobile apps. Nothing is written twice, and a model change reaches every component in the same release. See Architecture.
Delivery and operations
| Technology | Used for |
|---|---|
| Docker | Every server-side component ships as a container image for both amd64 and arm64. |
| Kubernetes and Helm | One namespace per organisation, deployed and upgraded from versioned Helm charts. |
| Gateway API routing | HTTPS routing to the web app and the API, with TLS terminated at the gateway. |
| Private container and package registry | Images, charts, Python packages and SDKs are distributed to partners through a private registry. |
| GitHub Actions | Continuous integration and release automation. |
Quality
- Automated tests run on every change: unit and API tests for the server, contract fuzzing against the OpenAPI document, component tests for the apps and end-to-end browser tests.
- Releases follow strict semantic versioning; release candidates are promoted unchanged to production.
- Container images are always referenced by an exact version, never by a moving tag.
See Deploying an Instance for what a partner needs to run the platform.