Appearance
Questionnaire Engine
The questionnaire engine is the part of Medipal that a patient actually sees and touches: the screens that present questions, collect answers, validate them, run the questionnaire's logic and hand the result back to the application that opened it. The same engine renders a questionnaire in the designer preview, in the admin web app when a clinician answers on a patient's behalf, in the patient mobile app (online and offline) and on public web pages for anonymous questionnaires.
This section explains how the engine is put together, how to build your own engine, how to add custom question components, and how a host application embeds an engine.
Three layers
| Layer | What it is | Who maintains it |
|---|---|---|
| Questionnaire core | The shared runtime. It understands the questionnaire model, drives navigation, evaluates logic and scoring, resolves languages, applies theme and zoom, and exposes a UI component library. | Medipal |
| Engine | A core version plus a set of question components (one per question type), packaged as a single self-contained HTML file. An engine decides how each question type looks and behaves. | Medipal (default engine) or you (custom engine) |
| Host | The application that loads an engine in an iframe, sends it a questionnaire and receives the submission: the admin web app, the patient mobile app or the anonymous questionnaire wrapper. | Medipal, or your own site for anonymous questionnaires |
The core never renders a question by itself. It renders the surrounding page (header, progress, navigation buttons, question text) and delegates the answer area to the component registered for the question's type. That is the extension point: a custom engine is nothing more than the core plus your own component set.
Why engines are packaged this way
- One file, no network. An engine bundle embeds its scripts, styles, icons and translations. It works inside the mobile app with no connectivity, and it renders identically in every host.
- Versioned and cacheable. Each engine has an identifier and a version. A published questionnaire is bound to a specific engine version, so a questionnaire keeps rendering the same way even after newer engines are released.
- Isolated. The engine runs in a sandboxed iframe and talks to its host only through messages. It has no access to the host page, its session or its data beyond what the host sends.
- Extensible by third parties. You can add question types that Medipal does not ship, restyle existing ones, or build a completely different look for a specific programme, without changing the platform.
How an engine reaches a questionnaire
- An engine is published to an engine store (a static file location) together with its manifest. Publishing happens from the web app's Engine Editor or with the engine builder tool.
- An administrator registers the engine on a folder. Folder configuration holds the list of available engines and cores, and the list is inherited by nested folders (see Folders & Configuration).
- When a questionnaire is created in that folder, it is bound to one of the registered engines. The engine's manifest tells the designer which question types exist and what each type's settings look like.
- When a questionnaire is published, its definition carries the engine identity and the engine's runtime options. Every host reads that information to know which bundle to load.
- A questionnaire can later be moved to another engine version from its configuration page (see Engine Editor).
Compatibility between core and engine
An engine is built against one core version and records it in its manifest. The core defines the component contract (props, events, shared helpers) and the runtime options an engine can expose. Upgrading the core of an engine means rebuilding the engine; hosts never combine a core and an engine on their own. Question types added by an engine become available to the designer only after the questionnaire is bound to that engine.
What to read next
| If you want to… | Go to |
|---|---|
| Understand what the engine does with a questionnaire | How Rendering Works |
| Package your own set of components as an engine | Building a Custom Engine |
| Write a new question type | Custom Question Components |
| Load an engine in your own application or web page | Embedding & Messaging |
| Manage engines from the admin web app | Engine Editor |
| Fix something that does not render as expected | Troubleshooting |