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 and carried 30 days of notice. lab_order_tests also gains a lab_order_state column.
Schema Changes
Release Highlights
Stable row identity for lab order testsuq_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:
- Anything that stores or joins on
uq_lab_order_testsneeds 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 = falsefilter.
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.