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.

​
Deleted care gaps are kept and flagged

Query early_release.caregaps, early_release.caregap_definitions, and early_release.caregaps_engagement. These tables are only present in Hosted Databases with Care Gaps enabled. Classified as a behavior change, so it carries seven calendar days of notice before GA. Every column keeps its name and type; what changes is which rows are in the tables. Today a care gap or care gap definition that is deleted disappears from the Hosted Database, and is_deleted is always false. In the ER tables a deleted gap or definition is kept and marked is_deleted = true, the same way deletions are handled on other Hosted Database tables. Most deleted gaps still carry status = 'open', because the gap was removed rather than closed, so this is the change most likely to move your numbers: across Hosted Databases with Care Gaps, counting open gaps without an is_deleted filter returns about 55% more rows than today, and in the most affected Hosted Database the caregaps table grows to more than three times its current size. Filter is_deleted = false on the ER tables to see only the gaps and definitions that are live today. What to check on your side:
  • Add is_deleted = false to any query that counts or lists care gaps or definitions, unless you want deleted ones included.
  • Compare open-gap counts by definition_id between caregaps and early_release.caregaps with that filter applied.

​
One row per patient tag

Query early_release.patient_tag. Classified as a behavior change, so it carries seven calendar days of notice before GA. Every column keeps its name, type, and meaning; what changes is how rows are kept up to date. Today, when a patient’s tag is changed to a different tag, patient_tag adds a row for the new tag and keeps the row for the old one, both with the same id. The patient then appears to carry both tags, and the old row continues to show a tag the practice has since replaced. In the ER table each id has exactly one row, carrying the patient’s current tag. Removed tags are still kept with deletion_time set, as they are today. The extra rows are dropped: none in most Hosted Databases, and up to 6.4% of the table in the most affected one. uq_patient_tag now identifies the patient tag alone, so its values differ from GA on every row. If you use it as the merge key for an incremental load, run a full reload against the ER table rather than merging into data built from GA values. id is unchanged. What to check on your side:
  • For a patient you know had a tag changed, expect one row per id carrying the current tag_value.
  • Counts of patients by tag_value no longer include tags that were later replaced.
  • Joins on id keep working as they do today.
Tag workflow context is in Patient Tags Guide.

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