Skip to main content
Early Release (ER) is an optional, separate Hosted Database channel. It carries changes that Elation has built and verified but has not yet rolled out to General Availability (GA), so you can query and test them before the GA date rather than waiting for it.

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 in the early_release schema. 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.
Early Release is opt-in and is requested per practice. It is not enabled by default.

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.

Fulfillment type and state on medication orders

Query early_release.med_order. Classified as a behavior change, so it carries seven calendar days of notice before GA. One pair of columns changes: fulfillment_type and fulfillment_state. Today both columns reflect the most recent fulfillment attempt on the order. An order sent electronically and later printed therefore reads as paper with a completed fulfillment, with no record that Surescripts ever succeeded. Cancel and change requests overwrite the original send the same way. In the ER table the columns report the successful electronic send when the order has one, then any completed delivery, then the last attempt. Cancel and change requests are ignored, because they act on an order that was already sent rather than delivering a new one. Grain is unchanged: one row per medication order, and no order loses a fulfillment it had today. The ER table carries the same columns as GA, but some appear in a different order. Select by column name; positional loads that assume GA column order should be checked against the ER table. What to check on your side:
  • Compare fulfillment_type and fulfillment_state on orders you know were sent electronically and later printed or changed.
  • Where you join on pharmacy identifiers, expect more rows to carry pharmacy_ncpdpid when the electronic send is the one reported.
Fulfillment values come from ePrescribing and ordering medications in the chart.

Recipient name on referrals

Query early_release.referral_order. Classified as a behavior change, so it carries seven calendar days of notice before GA. One column changes: send_to_name. Today send_to_name is populated only when a free-text recipient was entered on the referral. Referrals to someone in the provider directory show that person’s name in the chart, but the column stays blank in the Hosted Database when no free-text name was stored. In the ER table the column falls back to the name captured on the referral order when the free-text field is empty, so the name shown on the referral in the chart is the name you see in the query. No row that already had a send_to_name value changes. The column remains a display string — it may include credentials or an organization name — and the structured recipient_* columns are still the place to key on NPI or directory contact type where those exist. What to check on your side:
  • Compare recipient counts or top recipients against what you see in the chart for directory-based referrals.
  • Keep using recipient_* when you need structured recipient identity; use send_to_name when you need the label the practice saw on the letter.
Referral workflow context is in Letter & Referral Introduction.

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 the early_release schema in your Hosted Database alongside your existing GA tables. You can request access at any time, including specifically to test a single announced change.

Working with Early Release data

  • Query the early_release schema. Each pending change is published there under the same table name as GA — for example early_release.med_order alongside med_order. Point test queries and validation runs at the ER schema explicitly; a schema swap is enough to evaluate a change without rewriting table names in every query.
  • 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.
  • Column order can differ. ER tables are built on a parallel pipeline, so ordinal position may not match GA even when a column’s name and type are the same. Named selects are unaffected; positional exports or loads that rely on GA column order are not.

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 early_release schema, repoint them at the GA schema.
If you have any questions about this topic please reach out to Elation Support Portal with the subject line HDB - <your_question>