patient_problem_code table and resolves inconsistencies between how the Elation application (frontend) and the underlying data (backend) handled duplicate codes and deleted problems. Deletion is now represented by a single boolean is_deleted flag. The deletion_time and deleted_by_user_id columns are deprecated: they remain on the table but are now always null, and they will be fully removed at a future date.
Schema Changes
Release Highlights
Deletion represented as a singleis_deleted flag
Previously patient_problem_code carried both a deletion_time timestamp and a deleted_by_user_id reference alongside the is_deleted boolean. Deletion is now represented solely by is_deleted (true/false), which is the single source of truth for whether a patient problem code has been deleted. The deletion_time and deleted_by_user_id columns are deprecated — they still appear on the table for now but are always null, and they will be fully removed at a future date. Update any queries that read them to use is_deleted before that removal.
To exclude deleted rows, filter on the boolean directly:
- Duplicate codes. A single problem code could be backed by multiple underlying code records (for example, superseded or duplicate entries that resolve to the same code). These rows could disagree on deletion state, producing duplicate
patient_problem_coderows for the “same” code. Rows are now de-duplicated by the resolved code, so each code appears once with a single, consistent deletion state. - Deleted problems.
is_deletednow reflects deletion whether the patient problem itself was deleted or its underlying diagnosis-code link was removed, matching what the application displays. Previously a code could remain marked as not deleted in the data even though it no longer appeared in the application.