Form Builder & Submission — How it works

Overview

The form engine lets the platform define data-capture forms, publish immutable versions, target them to modules/facilities/clinical domains, and capture + process submissions. Form fields bind to concept ids (never raw tables), so captured data is coded and portable.

Data model & ownership

Area	Tables
Definition & versions	form_definition, form_version
Structure	form_section, form_field, form_field_option
Rules	form_validation_rule, form_conditional_rule
Targeting	module_form_mapping, facility_form_mapping, domain_form_target
Submission	form_submission, form_submission_processing_log

Key rules & invariants

• Published versions are immutable; structure is edited only on a draft (published = false), enforced by an assertDraft guard.
• Observation fields require a concept binding; coded options validate against the concept engine.
• Raw submissions are persisted first (RECEIVED), then validated/processed by a strategy; processing is logged and supports retry/override without losing the raw submission.

API

See the API Reference. Endpoint groups under /api/v1/form: form definitions, versions, structure (sections/fields/options), validation & conditional rules, module/facility/domain mappings, publication, and submissions (+ validation).

Configuration & feature flags

None.

Related features

• Concept (field bindings), Module / Facility (targeting), Clinical (captured observations). Domain plug-ins read via exchange.client.form.