Identify Changes to the Terminology
Got it — here’s the GitBook-ready version with no section or table numbering, fully cleaned up for a smooth read.
Overview
SNOMED CT release files include data that allows tracking of all changes between different versions of any edition of the terminology.
In addition to a unique id, each row in every release file includes:
effectiveTime – the date when the row became the effective version of that component or reference set member, either as a new component or a revision of the previous version.
active – indicates whether the component is still intended for active use.
moduleId – identifies the module that the component belongs to. A change to the moduleId indicates that a component has been moved to a different module, which may be:
another module maintained by the same organization, or
a module maintained by a different organization.
Minimum Review Checklist
Before updating to a newer SNOMED CT version, it is essential to:
Identify the inactivation of any concepts and descriptions used in:
data entry templates
picklists
reporting and analytics queries
Review changes to reference set memberships where these sets are used to assist or constrain data entry.
Consider broader review of changes to other reference sets used in reporting or analysis.
This section focuses on services that identify and categorize these changes. Additional services that provide more detail about some changes are described later in Get History Data.
Requirements and Options
To identify changes, terminology services must be able to:
Identify components and reference set members in the full release of the new version with an effectiveTime greater than the date of the previously installed version.
For each identified component:
Check active status in the updated release (active or inactive).
Check whether it existed in the previous release and, if so, its status there (active, inactive, or none).
Based on these results, determine:
The type of update.
Actions to consider.
Terminology Component Update Types
none
active
Addition
Component added since the previous release.
Concept/description: Consider including in templates, picklists, etc.Refset member: Assess impact if used in constraints for data entry or reporting.
active
active
Change
Component changed but remains active. May include property changes or moduleId reorganization.
Review nature of change and assess impact.
active
inactive
Inactivation
Component inactivated since the previous release.
Concept: Review/replace in templates, picklists, constraints, queries; use history data to find replacements.Description: Review/replace in templates, picklists.Refset member: Assess impact on data entry, mapping, reporting.
inactive
active
Reactivation
Component reactivated, possibly correcting an earlier inactivation.
Reverse any prior adjustments if applicable.
inactive
inactive
Remains inactive
Unusual case – remains inactive but has changed in some way.
No action required.
none
inactive
Inactivated addition
Likely added in an intermediate release, now inactivated.
No local action required, but be aware it may appear in data from systems using that intermediate release.
Services Required
Get components or reference set members that have changed since a specified previous release REQUIRED
Edition
Version release date/time (snapshot of components and refset members at this date/time represents the updated state)
Previous version release date/time (snapshot of components and refset members at this date/time represents the previous state)
Component type or reference set type
Optional: refsetId
Optional: Language/dialect
Identifiers of components or reference set members with the following characteristics:
specified component or reference set type
effectiveTime greater than previous release date/time (note that if only date is specified then component with any effectiveTime on that date must be excluded)
Indication of the update type. The update type indication should be applied either to:
the set of identifiers to which it applies; or
individually to each identifier.
Optionally other data associated with each changed component or reference set member could also be returned. However, requirements for additional data vary depending on the update type and the type of component or reference set. A service that returns sets of identifiers grouped by update type, and component or reference set type offers a more flexible solution. It allows additional data to be retrieved selectively by other services to support appropriate review of the changes.
Interdependencies
Required By
Other Services
Depends On
Select Edition and Version (including support for selecting two versions for comparison)
Service Examples
The Snowstorm and FHIR examples are presented in plain text and URL encoded versions. Always use the "Encoded URL" when testing the example service requests. The plain text version is included to aid readability but using this version in a service request may result in errors. These errors result from characters that have to be encoded as they are not permitted in a URL (see IETF RFC1738).
Snowstorm API
Get components or reference set members that have changed since a specified previous release
N/A
This service is not currently supported.
When Snowstorm is running with write access enabled it is possible to export SNOMED CT content selected by a range between two effective times. This process could be adapted to allow the relevant information to be processed in an application to identify the components and reference set members that have been updated. However, this would require the client application to process the selected data after it has been exported in the release file format.
FHIR API
Get components or reference set members that have changed since a specified previous release
N/A
This service is not supported.
MySQL Example Database
Get components or reference set members that have changed since a specified previous release
SELECT * FROM [snapshotTableName]
WHERE effectiveTime > [previousVersionDate];Example 1
* FROM `snap_concept`where `effectiveTime` > '2019-07-31';Example 2
SELECT * FROM `snap_description`
where `effectiveTime` > '2017-01-31';Example 3
CALL setSnapshotTime(1, '2019-07-31);
SELECT * FROM snap1_refset_simple
WHERE effectiveTime > '2018-07-31';
Returns all rows in the specified snapshot view of the named release file that have an effectiveTime is later than the specified previous version date. The snapshot time for the snapshot view determines the date of the current version.
Example 1 returns all rows in the current snapshot of the concept release file that have an effectiveTime after 2019-07-31.
Example 2 returns all rows in the current snapshot of the description release file that have an effectiveTime after 2017-01-31.
Example 3 sets a specific snapshot time 1 as (2019-07-31). It then returns rows from the simple reference set table in that specific snapshot view that have an effectiveTime after 2018-07-31.
Notes
The significance of changes to membership of reference sets depends on the extent to which they are used by a particular application. For example, a change to language reference set membership may mean that a description is no longer acceptable in the language or dialect used in by an application. Similarly, a change to a the membership of a simple reference set used to constrain a searches, reports or analytics may alter the results of those actions.
A delta release file may be available to provide information about changes since the previous release. However, in cases where an organization does not update the version they are using regularly, there may not be a single set of delta release files covering all the changes made between the version in use and the current version.
Language and/or dialect should be specified if the service returns terms associated with referenced concepts.
In the Snowstorm service requests [snowstorm] should be replaced by the URL to the Snowstorm server endpoint.
In the FHIR service requests [fhir] should be replaced by the URL to the FHIR terminology server endpoint. FHIR® is a registered trademarks of HL7 (www.hl7.org).
The SNOMED CT MySQL example database is not designed as a terminology server and is not intended for use in a live system. It is referenced in this guide as an illustration that some readers may find helpful. For more information about the SNOMED CT example database see the SNOMED CT - SQL Practical Guide. For instructions on how to build the example database refer to Appendix A: Building the SNOMED CT Example Database.
Note that to avoid issues if hours, minutes or seconds are included in previousVersionDate, the value should be set as 23:59:59 on the required date.
Last updated