Frontend Plugins

The Medipal web application can be extended without changing its source. A frontend plugin adds panels, buttons, tabs, pages and translations to the application through named extension points, and is packaged as a layer that the deploying partner includes in the application build.

What can be extended

Component slots — places in the interface where a plugin can render its own component:

Slot	Location	Typical use
navbar-actions	Top navigation bar, next to the user avatar	Global search, notifications
sidepanel-top	Side panel, after the menu	Additional navigation
sidepanel-bottom	Side panel, before the help icon	Status indicators, links
login-header	Login page, above the form	Announcements, branding
login-actions	Login page, below the credentials form	Single sign-on buttons
login-footer	Login page, after the form	Legal links, support contact
questionnaire-header-actions	Questionnaire detail page header	Export, share, integrations
patient-header-actions	Patient detail page header	Export, messaging
designer-toolbar-end	End of the questionnaire designer toolbar	Extra tools, preview modes

Tab registries — pages where a plugin can add a whole tab:

Registry	Page	Kind	Notes
dashboard-tabs	Dashboard	Component
user-profile-tabs	User profile	Component
admin-system-tabs	Admin panel → System	Component	Hidden unless the user has the scope the tab declares
admin-panel-tabs	Admin panel	Route	Provide a page; hidden unless the user has the declared scope
questionnaire-tabs	Questionnaire detail	Route	Provide a page
patient-tabs	Patient detail	Route	Provide a page

Component tabs render a component inside the page; route tabs link to a page the plugin ships.

Project structure

The plugin template, available from the private registry, has this layout:

my-plugin/
├── components/     UI components (auto-imported)
├── composables/    Reusable logic (auto-imported)
├── pages/          Pages added to the application's routes
├── plugins/        Registration of slots and tabs, translations merge
├── middleware/     Route guards
├── server/         Server-side endpoints the plugin needs
├── i18n/locales/   Translation files, merged into the application
├── assets/css/     Styles and design tokens
├── types/          Shared types
└── nuxt.config.ts  Plugin configuration and runtime settings

Delete the directories you do not use; only the registration plugin is required.

Registering into a slot or a tab

Registration happens in the plugin's registration file at application start-up. A component is registered against a slot name; a tab is registered against a registry key with a label, an icon, an order and either a component or a page path:

export default defineNuxtPlugin(() => {
  const slots = useExtendableSlotStore();

  slots.register("login-actions", MyLoginButton);

  slots.registerTab("patient-tabs", {
    label: "Care plan",
    icon: "lucide:heart-pulse",
    slot: "patient-care-plan",
    path: "patient-id-care-plan",
    order: 60,
  });
});

Tabs declared with a scope are shown only to users holding that scope, which keeps plugin features consistent with the platform's permission model.

Working with the platform

• API calls — use the application's API composable; it carries the signed-in user's session, so the plugin acts with that user's permissions.
• Configuration — declare runtime settings in the plugin configuration; the deploying partner sets their values per instance.
• Translations — put texts under a namespace of your own in the locale files; they are merged with the application's translations at start-up. Add a locale file for every language the application ships, or fall back to English.
• Styling — use the application's UI component library and design tokens so plugin panels match the rest of the interface.

Packaging and installation

1. Develop against a local copy of the web application by adding the plugin as a layer in its configuration.
2. Version and publish the plugin package to the private registry.
3. Ask the deploying partner to add the layer to the application build for the target instance and roll it out.

Plugins are part of the build, not loaded at runtime, so an instance's set of plugins is fixed per release. This keeps the application auditable and lets the partner test the combination before rollout.

Limitations

• A plugin cannot alter existing screens outside the listed slots and tab registries.
• Plugins run with the signed-in user's permissions; they cannot escalate them.
• Slot names are shared across all plugins; use distinctive tab identifiers to avoid collisions.