What Early Release is
When a change to the Hosted Database is ready but is still inside its notice period, or is waiting on a scheduled release date, Elation can build a copy of the affected table with the change already applied and share it into your Hosted Database as an additional table. The GA table is untouched, so nothing you have in production changes. That gives you two things:- Early access. If you are waiting on a new table or column to unblock work on your side, you can start querying it now instead of at the GA date.
- A place to test. Every change is fully validated by Elation before it reaches Early Release, so the channel is not where a change gets its first exercise. It is there so you can confirm the change lands cleanly in your environment: point a test run at the Early Release table and see your own pipelines and queries handle it before the change reaches the table they read today.
Currently in Early Release
The table below lists every change available in the ER channel today, with its GA date where one has been set. A blank GA date means the date has not been fixed yet. Select change notes on a row to read what is changing and what to check on your side.Stable row identity for lab order tests
Querylab_order_tests_early_release. Classified as a breaking change, so it carries 30 calendar days of notice before GA. Two things change.
1. The unique key becomes stable. uq_lab_order_tests today is derived from an identifier that Elation reissues every time a lab order is saved. Editing an order therefore leaves the old row in place and adds a new one, so the same test can appear against the same order several times. In the ER table the key 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 if you need to identify a row over time.
2. Removed tests stay visible. A test taken off an order currently disappears from the table. In the ER table it is retained and marked with a new is_deleted column. Add where is_deleted = false to see only the tests currently on an order.
What to check on your side:
- 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.
Provisioned Direct addresses on users
Queryuser_early_release. Classified as a breaking change, so it carries 30 calendar days of notice before GA. One column changes: direct_message_address.
Today the column is worked out from Direct messages a provider has received, so it holds the address the most recent inbound message was sent to. It is therefore blank for any provider who has never received a Direct message, which is why it is empty for many providers who can send and receive Direct messages perfectly well.
In the ER table the column 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.
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 lose their value. These are providers whose only address came from an inbound message, with no address provisioned against their record.
- 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 today is 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 stay blank in both tables. - Values are lowercased, as they are today.
How to request access
Contact the Elation Support Portal with the subject line HDB - Early Release access. Tell us which practice or practices you want it enabled for. Once it is enabled, the ER tables appear in your Hosted Database alongside your existing tables. You can request access at any time, including specifically to test a single announced change.Working with Early Release data
- Query the ER table by name. Each ER change arrives as its own table, sitting alongside the GA table it will eventually replace. Point test queries and validation runs at it explicitly. Nothing about how you query your existing tables changes.
- Do not run production reporting off it. The channel exists for validation and early adoption work. A change in ER can still be adjusted before GA.
- Expect only the affected tables. ER adds a table per pending change, not a duplicate of your Hosted Database.
Frequently Asked Questions
Does Early Release cost extra?
No. It is an optional channel available on request to Hosted Database customers.Is Early Release data real, and is it current?
Yes to both. It is your own data, not synthetic or sample data, and it is subject to the same access controls as the rest of your Hosted Database. ER tables are built on the same refresh cadence as your GA tables, so the only difference between the two is the pending change itself.What happens on the GA date?
The change lands in your GA table as described in its release notes, and the ER table is retired. If you built test queries against the ER table, repoint them at the GA one.Related Articles
If you have any questions about this topic please reach out to Elation Support Portal with the subject line HDB - <your_question>