medOS E-Form

Internal scope: ever-api-eform — electronic form definitions, versioned templates, and completed-form records.

medOS E-Form owns the platform's dynamic form engine: the form designer's data model, category and set organization, version/deploy lifecycle, completed-form records, and the prefill rules that auto-populate forms from patient and encounter context. It is the only backend service that uses PostgreSQL as its primary store (via TypeORM) rather than MongoDB, while still participating in the Moleculer service mesh over NATS like every other service.

11

Modules

PostgreSQL

Primary store

NATS

Transport

TypeORM

Data layer

Responsibilities

• Form definitions & versioning — create, update, duplicate, activate, deploy, and restore prior versions of a form definition.
• Organization — group forms into categories and sets, with per-user-role visibility for listing.
• Completed records — persist, list, count, cancel, and report on submitted form instances (eformRecord).
• Prefill — resolve patient and encounter data so new forms open pre-populated instead of blank.
• Designer backing store — host the Toolpad-based low-code designer's apps, releases, deployments, and DOM-node tree.
• User affordances — favorites and template-usage tracking so frequently used forms surface quickly.
• Numbering & settings — an internal sequence generator (prefix + running number) and a service-level settings store.

Major modules

Module	Purpose
eform	Core form-definition engine — create / update / duplicate / activate / deploy / restore-version / set report-printing.
eformCategory	Form categorization, including list-by-user-role.
eformSet	Groupings of related forms into a single set.
eformRecord	Completed/submitted form instances — create, list, count, cancel, report.
eformUseTemplate	Tracks which templates a user has applied.
eformFavorite	Per-user favorite forms.
eformPrefillData	Auto-population from patient (getPatientData) and encounter (getEncounterData) context.
toolpad	Low-code designer backing store — apps, categories, releases, deployments, DOM-node tree.
bidev	Form preview / development surface.
_sequence	Internal sequence generator (prefix lookup + running number) for form/record identifiers.
_setting	Service-level settings store.

Designer model

The toolpad module persists the designer's object graph in PostgreSQL across a small set of entities:

Entity	Role
toolpad.app	A designer application (one form / app).
toolpad.category	Designer-side categorization.
toolpad.release	An immutable snapshot of an app.
toolpad.deployment	A release promoted to a runnable deployment.
toolpad.domNode + toolpad.domNodeAttribute	The component tree and its attributes.

Designer (apps) ──release──▶ Release (snapshot) ──deploy──▶ Deployment (live)

This release-then-deploy split lets editors iterate freely while published forms stay pinned to a known release, complementing the version/restore lifecycle on eform itself.

Form lifecycle

 create ─▶ edit ─▶ activate ─▶ deploy ──▶ (in use)
   │         │                              │
   │         └── duplicate                  └── eformRecord (submissions)
   │                                              │
   └── restore-version ◀────────────────────────┘ report / cancel

A form definition moves through draft, active, and deployed states; submissions land in eformRecord and can be listed, counted, cancelled, or rolled up into reports. Prior versions remain restorable.

Engine

Definitions & versions

Create, duplicate, activate, deploy, and restore versioned form definitions.

Records

Submissions

Completed-form instances with list / count / cancel / report actions.

Designer

Toolpad

Low-code app, release, deployment, and DOM-node graph in PostgreSQL.

Prefill & integration

The eformPrefillData module bridges the form engine to clinical context: when a form opens it can request patient demographics and active-encounter fields so the form is pre-populated rather than blank. Because E-Form runs on the same NATS mesh, prefill resolution and form events are exchanged with sibling services through Moleculer service calls; an internal cache-clean event mixin keeps cached definitions fresh after edits.

PostgreSQL primary storeNATS / Moleculer meshPatient + encounter prefillRole-scoped listing

Config flags

Database connection is parameterized via environment variables (no hard-coded endpoints in deployment):

Variable	Purpose
TOOLPAD_DB_HOST	PostgreSQL host.
TOOLPAD_DB_PORT	PostgreSQL port.
TOOLPAD_DB_USER	Database user.
TOOLPAD_DB_PASSWORD	Database password.
TOOLPAD_DB_NAME	Database name.

TypeORM is configured with synchronize: false and migrationsRun: false, so schema changes are applied through explicit, reviewed migrations rather than implicit auto-sync.

Related catalog items

• CP-7, CP-8 — E-Form Designer & Permissions
• DEV-4 — E-Form Designer SDK

See also

• Backend Services Overview
• medOS Clinical — encounter context consumed by prefill
• Architecture Overview