Overview
High-level overview of the Missing Details feature: purpose, data model, and core concepts.
Overview
Continue patient registration and order creation even when some business-critical details are missing, while keeping a clean audit trail until those details are actually filled.
Missing Details
Missing Details is a cross-stack fallback-and-tracking system. It lets the lab move forward when patient or order data is unavailable right now, but it does not pretend the data is complete. Instead, it stores which field was missing, what placeholder/default value was used, where that happened, who did it, and whether the record has been resolved later.
In plain engineering terms: this feature is the safety rail between strict data quality and real-world front-desk chaos. The frontend lets the operator mark a field as missing and inject a configured default. The backend persists an unresolved LabMissingDetails row. Later, when a real value lands through patient update, order update, accession, or manual resolve, the system flips that row to resolved and keeps the trail intact.
Related Jira Tickets
| Ticket | Title | Notes |
|---|---|---|
EN-10733 | Missing Details | Primary feature ticket referenced for this guide |
Prerequisites
| Requirement | Why it matters | Where it is enforced |
|---|---|---|
Template data must exist in MissingDetailsTemplates | The config modal can only enable fields that exist as master templates | models/missing_details_templates.py, fixtures/missing_details_templates.json |
Lab-level config must be created in LabMissingDetailsConfiguration | Checkboxes only appear for configured fields | LabMissingDetailsConfigView (API) |
User must have missing_details_access to see the Missing Data module | The sidebar entry and primary UI are permission-gated | Registration SideBar, Organisation SideBar |
| Frontend must preload config into model state | The checkbox component hides itself if config is not loaded or the field is not configured | fetchLabMissingDetailsConfiguration, MissingFieldCustomCheckBox |
| For entity-backed defaults, the relevant create flow must be available | Some configured defaults bootstrap a referral/org/test/ICD/insurance/group entity behind the scenes | LabMissingDetailsConfiguration.process_field(...) |
| Session must identify lab and sometimes org scope | Missing detail rows are always lab-scoped and optionally org-scoped | LabMissingDetailsView, PY-2 registration/billing flows |
What Is It For
Frontend perspective
- Let staff keep the workflow moving instead of blocking registration or billing because one field is missing.
- Show a
Missingcheckbox only for fields the lab has explicitly configured. - Auto-fill a known placeholder/default value when the operator marks a field as missing.
- Keep enough generic state to know which config entry was used, what value was injected, and whether the UI should still show the checkbox or switch to a
Missing Datatag. - Show unresolved missing details on the waiting list, dashboards, accession pages, and the Missing Data tab.
- Give staff one-click routes into patient update or order update from the Missing Data tab.
Backend perspective
- Store lab-level defaults separately from actual missing-detail incidents.
- Create unresolved
LabMissingDetailsrows when a patient or order is saved with configured missing fields. - Resolve those rows automatically when a real value later differs from the stored placeholder value.
- Resolve those rows manually when the UI explicitly marks them resolved.
- Attach
has_missing_fieldsflags back onto bill and patient payloads so other screens can show red tags. - Create and log dependent entities for default values that are not plain strings, such as referral, organization, test, ICD, insurance, or group.
Types Of Missing Entities
| Type | Examples | What the default looks like | Extra entity creation needed | Runtime behavior |
|---|---|---|---|---|
| Static / value-only fields | Address, Email, Age, Patient ID, Contact Number, Order Number, Report Remark | Usually a plain string, number, or date | No | Frontend injects the configured value directly into the form |
| Select-backed but still straightforward fields | Nationality, Ethnicity, Race, Patient Type | A label/value that the frontend can construct locally | No backend entity creation | Frontend maps the configured value into the expected select object |
| Entity-backed patient fields | Referral, Organization, Allergies, Diseases, Clinical History, Insurance, Group | A name or code that should eventually exist as a proper domain entity | Yes, in many cases | Config save can bootstrap the entity; registration/billing then references it |
| Entity-backed order fields | Test, Test ICD code, Bill ICD codes, Consulting doctor | A catalog entity or coded object | Yes | Config save can create the entity, then billing/order update can use it |
Structure Of Missing Details
| Layer | What it stores | Table / state | Why it exists |
|---|---|---|---|
| Master template layer | Which fields are even eligible for Missing Details | MissingDetailsTemplates | Global catalog |
| Lab configuration layer | Which templates this lab has enabled and what default value to inject | LabMissingDetailsConfiguration | Per-lab behavior switchboard |
| Runtime incident layer (Transactional Data) | Every actual patient/order missing-field event | LabMissingDetails | Audit + resolution lifecycle |
| Entity creation trace layer | Which config caused a domain entity to be created | MissingDetailsEntityCreation | Observability + traceability |
There is also a fifth unofficial layer in practice: activity logs. They are not the source of truth for missing details, but they are the breadcrumb trail for entity creation activity, queueing, success, and failure.
Key Features
- Lab-specific configuration instead of a hardcoded global rule set.
- Soft-disable semantics for config rows, so historical references are not blown away.
- Runtime tracking at both patient level and order level.
- Automatic resolution when new real data differs from the stored placeholder.
- Manual resolution through Missing Data UI and related update flows.
has_missing_fieldsflag propagation into report/waiting/search style screens.- Organization scoping support through
org_idon runtime rows. - Collection-centre-specific UI gating so the feature does not leak into unsupported contexts.
- Legacy PY-2 compatibility for entity creation that still depends on old controllers.
- Local PY-3 entity creation for some insurance/group flows where migration work has already happened.