Skip to main content
This release brings the two changes announced on 2026-10-02 to General Availability. patient_tag keeps one row per patient tag, carrying its current tag, and the care gaps tables keep deleted gaps and definitions marked is_deleted = true rather than dropping them. Both were classified as behavior changes under Change Management and carried seven days of notice. No columns are removed or renamed.

​
Schema Changes

​
Release Highlights

One row per patient tag When a patient’s tag was changed to a different tag, patient_tag added a row for the new tag and kept the row for the old one, both with the same id. The patient then appeared to carry both tags. Each id now has exactly one row, carrying the patient’s current tag. Removed tags are still kept with deletion_time set. Rows left behind by earlier tag changes are removed. What to check on your side:
  • If you load patient_tag incrementally keyed on uq_patient_tag, run a full reload. Every value has changed, so merging into data built from the old values leaves duplicates. id is unchanged.
  • Counts of patients by tag_value no longer include tags that were later replaced.
Tag workflow context is in Patient Tags Guide. Deleted care gaps are kept and flagged These tables are only present in Hosted Databases with Care Gaps enabled. A care gap or care gap definition that was deleted used to disappear from the Hosted Database, and is_deleted was always false. Deleted gaps and definitions are now 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 before. 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.
The early_release.patient_tag, early_release.caregaps, early_release.caregap_definitions, and early_release.caregaps_engagement tables stay available for one more week so you can compare them against GA, then they are retired. If you pointed test queries at the early_release schema, repoint them at the GA tables. The changed columns are described in the Hosted Database schema. If you have any questions about this topic please reach out to Elation Support Portal with the subject line HDB - <your_question>