Skip to content

fix(stoptb): store Nikshay ID on i_beneficiarydetails, not tb_suspected - #187

Merged
SauravBizbRolly merged 1 commit into
release-3.9.0from
vb/nikshay-beneficiarydetails-fix
Sep 14, 2026
Merged

fix(stoptb): store Nikshay ID on i_beneficiarydetails, not tb_suspected#187
SauravBizbRolly merged 1 commit into
release-3.9.0from
vb/nikshay-beneficiarydetails-fix

Conversation

@vishwab1

Copy link
Copy Markdown
Member

The import previously fabricated a brand-new tb_suspected row for any beneficiary who didn't already have one, just to hold the generated Nikshay ID. tb_suspected is a clinical table (is_confirmed, is_referred, reason_for_suspicion, etc.) — inserting a bare row there falsely implied the beneficiary had been assessed as a TB suspect when no such assessment ever happened, and every beneficiary needs a Nikshay ID regardless of suspect status.

A Nikshay ID is a beneficiary-level identifier, not a clinical fact, so it now lives on db_identity.i_beneficiarydetails (nikshayId, nikshayCreatedByAmrit — new columns, migration to follow separately in AMRIT-DB) alongside similar existing identifiers like rchid on i_beneficiarydetails_rmnch.

  • NikshayExportRepository: existingNikshayId now reads d.nikshayId (already-joined i_beneficiarydetails) instead of a tb_suspected subquery. Replaced findLatestSuspectedId/updateNikshayId/ insertSuspectedWithNikshayId with a single writeNikshayId() — always an UPDATE via i_beneficiarymapping.BenRegId -> BenDetailsId, never an INSERT, since every beneficiary reaching this point already has a synced i_beneficiarydetails row.
  • NikshayImportService: calls writeNikshayId() directly and reports a failed row if it updates zero rows, instead of silently dropping the generated ID.

tb_suspected is no longer touched by this feature.

📋 Description

JIRA ID:

Please provide a summary of the change and the motivation behind it. Include relevant context and details.


✅ Type of Change

  • 🐞 Bug fix (non-breaking change which resolves an issue)
  • New feature (non-breaking change which adds functionality)
  • 🔥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 🛠 Refactor (change that is neither a fix nor a new feature)
  • ⚙️ Config change (configuration file or build script updates)
  • 📚 Documentation (updates to docs or readme)
  • 🧪 Tests (adding new or updating existing tests)
  • 🎨 UI/UX (changes that affect the user interface)
  • 🚀 Performance (improves performance)
  • 🧹 Chore (miscellaneous changes that don't modify src or test files)

ℹ️ Additional Information

Please describe how the changes were tested, and include any relevant screenshots, logs, or other information that provides additional context.

The import previously fabricated a brand-new tb_suspected row for any
beneficiary who didn't already have one, just to hold the generated
Nikshay ID. tb_suspected is a clinical table (is_confirmed, is_referred,
reason_for_suspicion, etc.) — inserting a bare row there falsely implied
the beneficiary had been assessed as a TB suspect when no such
assessment ever happened, and every beneficiary needs a Nikshay ID
regardless of suspect status.

A Nikshay ID is a beneficiary-level identifier, not a clinical fact, so
it now lives on db_identity.i_beneficiarydetails (nikshayId,
nikshayCreatedByAmrit — new columns, migration to follow separately in
AMRIT-DB) alongside similar existing identifiers like rchid on
i_beneficiarydetails_rmnch.

- NikshayExportRepository: existingNikshayId now reads d.nikshayId
  (already-joined i_beneficiarydetails) instead of a tb_suspected
  subquery. Replaced findLatestSuspectedId/updateNikshayId/
  insertSuspectedWithNikshayId with a single writeNikshayId() — always
  an UPDATE via i_beneficiarymapping.BenRegId -> BenDetailsId, never an
  INSERT, since every beneficiary reaching this point already has a
  synced i_beneficiarydetails row.
- NikshayImportService: calls writeNikshayId() directly and reports a
  failed row if it updates zero rows, instead of silently dropping the
  generated ID.

tb_suspected is no longer touched by this feature.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Sep 14, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: b0ad1dd6-f33f-4cdc-ac58-3521e4168289

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@sonarqubecloud

Copy link
Copy Markdown

Quality Gate Failed Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

@SauravBizbRolly
SauravBizbRolly merged commit 71f68ea into release-3.9.0 Sep 14, 2026
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants