Appendix C: Release Types and Versioned Views
Release Types
SNOMED CT release packages include the following distinct representations of the terminology content.
A full release, which is a release type in which the release files contain every version of every component and reference set member ever released.
A snapshot release, which is a release type in which the release files contain only the most recent version of every component and reference set member released, as at the release date.
Versioned Views
A versioned view is formally defined as:
A set of component versions and reference set member versions defined by characteristics of their effectiveTimes.
From a practical perspective, a versioned view is the result of filtering the full release files based on criteria that return a consistent representation of the content of these files as it was (or would have been) at a particular point in time.
Notes
Versioned views and release types are closely related. A release type is a physical representation of a particular versioned view.
Some versioned views are not instantiated as release types but all valid versioned views of a SNOMED CT edition can be generated from a full release of that edition.
A delta view is a view of SNOMED CT that contains only rows that represent changes to components and reference set members since a specified date or between two specified dates in the past.
A full view is a view of SNOMED CT that includes all versions of all components and reference set members in a full release.
A snapshot view is a view of SNOMED CT that includes the most recent version of all components and reference set members at a specified point in time.
The three main versioned views are:
The full view, which is a view of SNOMED CT that includes all versions of all components and reference set members in a full release.
A snapshot view which is a view of SNOMED CT that includes the most recent version of all components and reference set members at a specified point in time.
There are two distinct types of snapshot view:
A current snapshot view, which is a snapshot view for the date of the most recent release.
A retrospective snapshot view, which is a snapshot view for a specified snapshot date.
A delta view, which is a view of SNOMED CT that contains only rows that represent changes to components and reference set members since a specified date or between two specified dates in the past.
There are two distinct types of delta view:
The current delta view, which is a delta view for the date range between the most recent release date and the immediately preceding release date.
A retrospective delta view, which is a delta view for a specified date range.
See also Enabling Versioned Views
Practical Uses for Versioned Views
The practical uses of these views are outlined in the table below.
Practical Uses for Different Versioned Views
Full view
This view contains all versions of all released components and reference set members.
It can support all the uses identified in the following rows of this table.
Current snapshot view
This view contains only the most recent version of all released components and reference set members.
It should be used for data entry.
It can also be used to support for most types of retrieval and analysis.
Detailed analysis of past use of concept that have since been made inactive may benefit from access to previous snapshots.
It can also be used to generate the current delta view and thus also enables the uses identified for that view.
Retrospective snapshot view
A retrospective snapshot view has the same features as a current snapshot view but excludes changes made after a certain point in time.
During and immediately after upgrading to a new release version, the previous snapshot view map be of particular value for determining details of changes.
Earlier snapshot views can also be valuable when comparing and evaluating results of analyses which may have been affected by terminology changes.
Current delta view
This view only includes the post change state of components that have changed since the previous release.
It can be used to identify components that have been added or inactivated since the previous release and this information can be used to check whether updates are needed. For example, updating, implementation resources such as local subsets, data entry picklists and queries. These updates may include removing inactive concepts or descriptions as well as adding relevant newly added concepts and descriptions.
Note that some aspects of this review process also require access to the previous current snapshot view.
Retrospective delta view
A retrospective delta has the same features as a current delta view but relates to changes between two earlier dates.
It can be used in conjunction with snapshot views
Release Type Support for Versioned Views
A key factor when deciding which release type(s) to import is the extent to which each release by supports required views of the terminology content. The table below lists the views that may be required and indicates which release types support each of these views.
Table 1: Views Supported by Different Release Types
Supported Views
Release Types
Full
Snapshot
Delta
Full View
A view of SNOMED CT that includes all versions of all components and reference set members in a full release.
Snapshot Views
Current Snapshot
A snapshot view for the date of the most recent release.
Retrospective Snapshot
A snapshot view for a specified snapshot date.
Delta Views
Current Delta
A delta view for the date range between the most recent release date and the immediately preceding release date.
Retrospective Delta
A delta view for a specified date range.
Common Mistakes with Snapshot Generation
The most common type of error when generating a snapshot is to ignore considerations pertaining to dates and active status. For example, it is reasonable to want to filter a view so that only active components are included. However, if you apply that filter in a way that restricts the substrate from which the snapshot is generated you will get incorrect results in which all components appear to be active even after they have been inactivated. An example of this error has been presented below.
Table 2: Full Release as at 2019-01-31
A
20170131
1
Red
B
20170131
1
Amber
C
20170131
1
Yellow
A
20180131
0
Red
B
20180131
1
Orange
D
20180131
1
Green
B
20190131
0
Orange
E
20190131
1
Blue
The following query when applied to the full release data shown in Table 2 generates the erroneous snapshot view shown in Table 3. This query excludes inactive rows at the same time as identifying the most recent effectiveTime. The result is that components A and B are shown as active because the later rows that inactivated those components were excluded.
Select * from `component` `c` where
`c`.`effectiveTime`=(Select max(effectiveTime) from `component` where `id`=`c`.`id` and active=1)Table 3: Erroneous Snapshot view as at 2019-01-31
A
20170131
1
Red
C
20170131
1
Yellow
B
20180131
1
Orange
D
20180131
1
Green
E
20190131
1
Blue
The following query when applied to the full release data shown in Table 2 generates the correct snapshot view shown in Table 4. The most recent versions of all the components A-E are included. In the case of components A and B these are both inactive.
Select * from `component` `c`
where `c`.`effectiveTime`=(Select max(effectiveTime) from `component` where `id`=`c`.`id`)Table 4: Correct Snapshot view as at 2019-01-31
C
20170131
1
Yellow
A
20180131
0
Red
D
20180131
1
Green
B
20190131
0
Orange
E
20190131
1
Blue
The following query when applied to the full release data shown in Table 2 generates the correct snapshot view shown in Table 5 with inactive rows filtered out after generating the snapshot view. Only components C-E are included as the most recent versions of components A and B are inactive.
Select * from `component` `c`
where `c`.`active`=1
and `c`.`effectiveTime`=(Select max(effectiveTime) from `component` where `id`=`c`.`id`)Table 5: Correct Snapshot view as at 2019-01-31 with inactive rows excluded
C
20170131
1
Yellow
D
20180131
1
Green
E
20190131
1
Blue
Last updated