> ## Documentation Index
> Fetch the complete documentation index at: https://help.elationhealth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-07-28

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. 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

| Table                  | Column               | Change                                                                                       |
| ---------------------- | -------------------- | -------------------------------------------------------------------------------------------- |
| patient\_problem\_code | `deletion_time`      | Deprecated — column remains but is now always `null`; will be fully removed at a future date |
| patient\_problem\_code | `deleted_by_user_id` | Deprecated — column remains but is now always `null`; will be fully removed at a future date |
| patient\_problem\_code | `is_deleted`         | Now the only indicator of deletion state                                                     |

***

## 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. 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:

```sql theme={null}
select *
from patient_problem_code
where is_deleted = false
```

**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](/articles/support-portal-introduction) with the subject line HDB - \<your\_question>*