Workflow Guide

This section provides a practical walkthrough that gives context to understand the feature's behavior without digging through implementation details.

Configuring (Enabling/Disabling) The Missing Details Default Values

The configuration UI lives under advanced registration settings and is the source of truth for which fields can be marked missing.

Where the user goes

1. Open the registration settings / advanced settings area.
2. Look for the section labeled Registration/Order Creation With Missing Details.
3. If nothing is configured yet, the button shown is Enable.
4. If configs already exist, the buttons shown are Edit and Disable.

Source references:

• AdvanceSettings.tsx
• MissingDetailsModal.tsx

What the buttons do

What happens inside the Missing Details modal

1. The frontend calls getTemplates() to fetch MissingDetailsTemplates.
2. In parallel it calls getLabConfigs() to fetch the current active lab config.
3. The modal shows:
   • a category dropdown,
   • a field selector with Select All,
   • a table of selected fields,
   • a Default Value If Missing column,
   • action icons for edit/remove.
4. The operator can:
   • add one field,
   • add all fields in the filtered category,
   • edit a default value,
   • remove a field from active config.

Validation checks before save

These checks happen in the frontend before saveLabConfigs(...) posts the payload.

Fields that are effectively non-editable after config exists

The UI disables default-value editing for fields listed in NON_EDITABLE_FIELD_NAMES. These include items like Clinical History, Allergies, Referral, Organization, Test, Bill ICD codes, Consulting doctor, and a few more.

Save payload structure

The modal computes three buckets before save:

Posted to:

• POST /api-v3/registration/patients/lab-missing-details-config

Backend behavior on config save

The PY-3 config view performs these steps:

1. Resolve lab_id from session.
2. Validate payload with LabMissingDetailsBulkUpdateSerializer.
3. Create new LabMissingDetailsConfiguration rows for genuinely new templates.
4. Soft-disable rows listed in disabled_ids.
5. Bulk-update changed rows.
6. For each created config, call LabMissingDetailsConfiguration.process_field(...).

process_field(...) decides whether the configured default is plain data or a real entity that the system should create somewhere else. For example, referrals, organizations, tests, and some insurance/group entities may be created or queued for creation.

Enabling vs disabling in real DB terms

This is not hard delete.

Registering A Patient With Missing Details

The operator flow in registration

1. Open the patient registration form.
2. The frontend loads labMissingDetailsConfiguration into model state through fetchLabMissingDetailsConfiguration(...).
3. For configured fields, the UI can show a Missing checkbox near the field.
4. The operator clicks the Missing checkbox.
5. MissingFieldCustomCheckBox immediately updates:
   • missingFieldState[field] = true
   • missingFieldUIVisible[field] = false
6. The checkbox's onToggle handler calls handleMissingToggle(...).
7. handleMissingToggle(...) looks up the configured default value and config id.
8. The correct form field is populated.
9. The helper persists:
   • missingFieldSavedValue[field] = injected value
   • missingFieldConfigUsed[field] = config id
10. The visible UI switches from the checkbox to a Missing Data label in many places.

What happens if the user later types a real value

If the field was marked missing and the current form value no longer matches the injected saved value, the frontend clears the missing state via checkAndResetMissingField(...).

Registration submit payload

When patient registration is submitted, the payload carries the selected missing config ids (e.g., labMissingDetailsIds, labMissingFieldIds).

Backend registration path

In PY-3:

1. Patient save lands in UserDetails.after_save(...).
2. build_value_mapper(self, insurance_details) converts the saved object into a flat string map of fields.
3. create_or_update_missing_details_entries(...) is called with lab_missing_field_ids, lab_id, user_details_id, and context.
4. The function decides whether to create new unresolved rows or resolve existing ones.

Registering / Updating An Order With Missing Details

Order-level missing fields follow the same idea but run through billing/update surfaces instead of pure patient registration.

Typical order-level examples include Test, Order Number, Report Remark, Bill ICD codes, Test ICD codes, Consulting doctor.

Billing flows populate missingFieldConfigUsed and send labMissingFieldIds on create/update so backend paths can resolve or create runtime rows.

Resolving Missing Data

Resolution modes:

• Automatic resolution: user edits patient/order data and saves a different real value.
• Manual bulk/manual resolution: user clicks resolve in Missing Data UI.
• Clinical-info resolution: updates from accession clinical info.
• Waiting-list resolve modal: review and mark resolved.

Patch API:

PATCH /api-v3/account/missing-details/lab-fields expects:

{
  "ids": [101, 102],
  "is_resolved": true
}

Behavior:

• resolved_at is set when is_resolved=true.
• resolved_at is cleared when is_resolved=false.

Watch the short walkthrough showing how to resolve missing rows from the Missing Data UI:

Where missing details are visible to the user

Example: Missing tag in Org / CC view

This screenshot shows how a patient registered with missing details appears in an Org/CC login, including the Missing tag on the list row.