> ## 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-09-14

This release brings the two changes announced on 2026-08-14 to General Availability. `lab_order_tests` gains a stable unique key and keeps tests that have been removed from an order, and `user.direct_message_address` now holds the Direct address Elation has provisioned for a provider. Both were classified as breaking changes under [Change Management](/articles/hdb/change-management) and carried 30 days of notice. `lab_order_tests` also gains a `lab_order_state` column.

## Schema Changes

| Table             | Column                   | Change                                                                                                                                        |
| ----------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
| lab\_order\_tests | `uq_lab_order_tests`     | Now identifies the pairing of an order and a test, and is stable across edits to the order. The values change                                 |
| lab\_order\_tests | `is_deleted`             | New — a test removed from an order is retained and marked rather than disappearing                                                            |
| lab\_order\_tests | `lab_order_state`        | New — the tracking state of the parent lab order                                                                                              |
| user              | `direct_message_address` | Now the Direct address Elation has provisioned for the provider, rather than the address inferred from the most recent inbound Direct message |

***

## Release Highlights

**Stable row identity for lab order tests**

`uq_lab_order_tests` was previously derived from an identifier that Elation reissues every time a lab order is saved. Editing an order left the old row in place and added a new one, so the same test could appear against the same order several times. The key now identifies the pairing of an order and a test, so editing an order updates the row that is already there.

The `id` column still carries the underlying link identifier, and it still changes on every save. Use `uq_lab_order_tests` when you need to identify a row over time.

A test taken off an order previously disappeared from the table. It is now retained and marked with the new `is_deleted` column. Add `where is_deleted = false` to see only the tests currently on an order:

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

**What to check on your side:**

* Anything that stores or joins on `uq_lab_order_tests` needs repointing, because the values change.
* Any query that counts rows in this table will return a different answer. Duplicates from edited orders go away, and removed tests appear for the first time.
* Any query that treats the presence of a row as proof a test is still ordered needs the `is_deleted = false` filter.

**Lab order state on each test**

`lab_order_state` is the tracking state of the parent lab order, carried onto each of its tests so you can find the tests on outstanding orders without joining back to `lab_order`.

The value mirrors `lab_order.order_state` exactly, so a test's state always agrees with its order. It is blank where the order has no resolution record yet, which is the case for roughly two fifths of rows today, so treat a null as "no state recorded" rather than as a state in its own right.

This is not the same as `lab_order.order_status`, which is an HL7 result status code inherited from the resolving report. Where you are asking about the progress of an order rather than the status of its result, `lab_order_state` is the column you want.

**Provisioned Direct addresses on users**

`direct_message_address` was previously worked out from the Direct messages a provider had received, so it held the address the most recent inbound message was sent to. It was blank for any provider who had never received a Direct message, which is why it was empty for many providers who can send and receive Direct messages perfectly well.

The column now holds the Direct address Elation has provisioned for that provider, taken from their provider record and falling back to their entry in the shared provider directory. This is the same address Elation itself sends from, so it matches what the provider sees in the application. Where neither source holds an address, the address inferred from the most recent inbound message is still used, so no row loses the value it had before.

**What to check on your side:**

* Far more rows are populated. If you count providers with a Direct address, or filter on the column being present, expect the answer to grow substantially.
* A small number of rows change to a different address. These are mostly cases where the inbound message was addressed to another practice's Direct domain, so the value published previously was not that provider's own address.
* The column is populated for rows with `user_type = 'physician'` only. Staff and system users hold no Direct address in any Elation source and remain blank.
* Values are lowercased, as they were before.

The new and changed columns are described in the [Hosted Database schema](/articles/hdb/schema).

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