Skip to main content
This release simplifies how deletion is represented on the patient_problem_code table and resolves inconsistencies between how the Elation application (frontend) and the underlying data (backend) handled duplicate codes and deleted problems. The deletion_time and deleted_by_user_id columns are removed in favor of a single boolean is_deleted flag.

Schema Changes


Release Highlights

Deletion represented as a single is_deleted flag Previously patient_problem_code carried both a deletion_time timestamp and a deleted_by_user_id reference alongside the is_deleted boolean. These have been consolidated: deletion_time and deleted_by_user_id are removed, and is_deleted (true/false) is now the single source of truth for whether a patient problem code has been deleted. To exclude deleted rows, filter on the boolean directly:
Consistent duplicate and deletion handling We also resolved cases where the deletion state in the Hosted Database could disagree with what the Elation application shows. Two sources of inconsistency were addressed:
  • 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_code rows 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_deleted now 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.
If you have any questions about this topic please reach out to Elation Support Portal with the subject line HDB - <your_question>