Skip to content

Conversation

@Gyan-Gupta-Rtsl
Copy link
Contributor

@Gyan-Gupta-Rtsl Gyan-Gupta-Rtsl commented Jan 14, 2026

Story card: sc-17719
Refer to this Slack thread for more context: Slack-thread

Because

diagnosed_confirmed_at was remaining nil when medical histories were created while patient.recorded_at was still unset. The old backfill depended on patient.recorded_at, so any missing recorded_at caused diagnosis timestamps (htn/dm) to stay nil.

This addresses

Updates the backfill source to use medical_history.device_created_at to populate diagnosis dates consistently for existing patients.

Test instructions

Run the migration and verify diagnosis dates are populated for existing records.

Copy link
Contributor

@aagrawalrtsl aagrawalrtsl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion we should not change this migration because it has already been run in production instances, there is no use of changing it now.
We can discuss this over on a call as well to get more clarity on this

SET diagnosed_confirmed_at = recorded_at
WHERE diagnosed_confirmed_at IS NULL
AND recorded_at IS NOT NULL;
SQL
Copy link
Contributor

@aagrawalrtsl aagrawalrtsl Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the existing patients in production have recorded_at present. So, this updating diagnosed_confirmed_at = recorded_at is correct. For existing patients we want to capture when the patient was diagnosed and patient's registration time is the only timestamp present in the current flow, which we can use of.
My opinion - patients registered in the new flow had missing diagnosed_confirmed_at (which is now fixed), after this migration ran, all patients had a valid diagnosed_confirmed_at. So we don't have to remove this part.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only concern is around long-term clarity. If existing patients have diagnosed_confirmed_at derived from patient.recorded_at, while newer patients derive it from medical_history.device_created_at, the same field would represent different source semantics across cohorts. This could be confusing for future analysis or debugging unless clearly documented.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, but for ET, we would have to manually revert this migration, and then re run it again.
I am not sure whether it would cause any more issues or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think reverting and re-running this migration on ET could be risky. To avoid any issues with migration history, I am thinking is to keep this migration unchanged and handle ET via a one-time, scoped backfill through a script executed safely via the Rails console for existing records. Since the updated code is currently deployed only on ET, we can apply this fix specifically there. For other environments where the code is not yet deployed, the migration will run as intended and handle the backfill correctly when deployed.

)

earliest = [htn_time, dm_time].compact.min
mh.patient.update_columns(diagnosed_confirmed_at: earliest) if earliest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will not work for all the patients because for some medical_histories hypertension/dm = unknown (in production). For these patients diagnosed_confirmed_at would still remain null.
In my opinion - we don't want that. Instead we want all the existing patients to be treated as a regular diagnosed patient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants