Overview
Architecture summary, supported form types, and key source locations for the Lab Forms module
Backend Overview
For a user-facing overview of Lab Forms (what they are, form types, and how they work), see the Lab Forms Overview.
The Lab Forms module is a configurable form engine used across CrelioHealth's LIMS platform. It powers several form use-cases — Consent, Ask-at-Order-Entry (AOE) and Additional Patient Info — through a single, shared data model and API layer.
Architecture Summary
Terminology Mapping
| User-facing term | Code entity | Description |
|---|---|---|
| Form | Process | The main form container |
| Section | SubProcess | A group of questions within a form |
| Question | Question | An individual field/prompt |
| Question property | QuestionAttribute | Validation, options, skip logic metadata |
| Linked tests/profiles | ProcessLinkedInstances | Which tests/profiles a form applies to |
| Captured answer | QuestionValue / AdditionalPatientInfo | Stored response data |
Key Source Locations
| Layer | Path |
|---|---|
| Models | admin/account/models/coc/ |
| Views | admin/account/views/lab_forms/ |
| Serializers | admin/account/serializers/custom/lab_form_* |
| URLs | admin/account/urls/coc_urls.py, admin/account/urls/patient_consent_urls.py |
| Helpers | admin/account/lab_form_helpers/ |
| Constants/Utils | admin/account/utils.py (PROCESS_TYPE_MODEL_META_MAPPER, email templates) |
Supported Form Types
Defined in admin/account/models/coc/lab_form.py:
| Form Type | Description |
|---|---|
aoe | Ask at Order Entry — captures clinical questions at the point of billing |
consent | Patient Consent — collects communication preferences and legal consent |
additional_patient_info | Extra patient demographic/clinical info |
Instance-ID Dependent Form Types
aoe and consent support linking a Process to specific entity instances (tests, profiles and promotions) via ProcessLinkedInstances.
For instance-dependent process types such as Test, Profile, and Promotion question values are persisted at the lab report level. Since reports are generated per test, values are ultimately stored against each test's lab report ID.
This means:
- If a profile is billed and AOE is configured at the profile level, AOE may be captured once in the UI, but values are saved separately for each test in that profile (against each corresponding report).
- If the profile itself does not have direct AOE mapping, but specific tests inside the profile do, values are captured and stored only for those mapped tests against their respective report IDs.
The same persistence rule applies to Consent and Promotion process types: capture may appear centralized, but storage remains test/report scoped.