> ## 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. The `deletion_time` and `deleted_by_user_id` columns are removed in favor of a single boolean `is_deleted` flag.

## Schema Changes

| Table                  | Column               | Change                                   |
| ---------------------- | -------------------- | ---------------------------------------- |
| patient\_problem\_code | `deletion_time`      | Removed                                  |
| patient\_problem\_code | `deleted_by_user_id` | Removed                                  |
| 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. 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:

```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>*