IHTSDO Deprecation Policy
Date 20140819
Version 1.0
Amendment History
Version
Date
Editor
Comments
0.02
20120624
Julie Richards
0.03
20120714
Julie Richards
Separated policy from procedure
Many other changes
0.04
20120724
Julie Richards
Updates from 20120724 conference call
0.05
20120730
Julie Richards
Incorporated Jane Millar’s comments
0.06
20120801
Julie Richards
Clean up and grammar corrections
0.07
20130214
Jane Millar
0.08
20130404
Jane Millar
0.09
20130916
Julie Richards
Update taking into account consultation with
IHTSDO Standing Committees
Comments incorporated from development
group
Editorial comments cleaned up and mark up of
content comments
0.10
20130924
Julie Richards
Major updates after consultation review 1
0.11
20130928
Julie Richards
0.12
20131009
Julie Richards
0.13
20140421
Julie Richards
0.14
20140429
Julie Richards
1.0
20140819
Julie Richards
Minor updates incorporating Jeremy Thorp and
Jane Millar’s comments
Updates incorporating feedback from Quality
Assurance Committee.
First version after Review 2 incorporating
comments received.
Version approved by QAC for recommendation
to the Management Board.
Final version after review by MB and approval
by CEO.
Version
Date
Approver
Comments
1.0
20140730
Don Sweete, CEO
Approvals
Review Timetable
Review date
Responsible owner
20160730
Head of Delivery
Comments
© International Health Terminology Standards Development Organisation 2014. All rights reserved.
IHTSDO Deprecation Policy
Table of Contents
1 Overview .................................................................................................................................1 1.1 Introduction .................................................................................................................................... 1 1.2 Purpose ......................................................................................................................................... 1 1.3 Definitions of Deprecation and Related Terms .............................................................................. 1 1.4 Audience ....................................................................................................................................... 2 1.5 Scope ............................................................................................................................................ 2 2 Deprecation Considerations ....................................................................................................3 2.1 Reasons for Deprecation ............................................................................................................... 3 2.2 Declaration of Level of Support for Deprecated Artifact ................................................................ 3 2.3 Deprecation Process ..................................................................................................................... 4 3 IHTSDO Deprecation Policies .................................................................................................4 4 Process for Review of this Policy ............................................................................................4 IHTSDO Deprecation Policy
1 Overview
1.1 Introduction
The IHTSDO and its member National Release Centers (NRC) are responsible for the maintenance
and publication of IHTSDO products, SNOMED CT being a major example.
In the creation, implementation and maintenance of health solutions, it is recognized that changes will
occur over time and thus there is a need for formal deprecation processes. Changes will be driven by
many factors, including changes in the business of health; enhancements in technology and others.
The changes can occur across all types of artifacts, including SNOMED CT itself, SNOMED CT format
type, mappings to other terminologies, reference sets as well as IHTSDO approved documentation
and standards. It is common practice that the level of service support provided to releases of an
artifact will decrease and/or stop once an artifact has been deprecated. In addition, the need for
change and potential for deprecation may be prompted by developments within other Standards
Development Organizations.
It is important that everyone involved in the development, implementation and maintenance of any
IHTSDO product including one or more artifacts, understands the IHTSDO Policy related to
deprecation.
This policy document is accompanied by two additional deprecation documents: one that describes
the process to follow for deprecation; and one that facilitates the consultation and approval processes
during deprecation:
• IHTSDO Deprecation Process
• IHTSDO Deprecation Consultation & Review Template
1.2 Purpose
This Policy has been developed to ensure that:
- the term deprecation and how it applies to IHTSDO artifacts is understood;
- a process is followed that consults with the community to minimize the adverse effects of
deprecation and maximize the beneficial effects; and
- the user community understands how they are involved in the process and has the opportunity
to provide feedback on the deprecation being proposed.
1.3 Definitions of Deprecation and Related Terms
1.3.1 Deprecation
Deprecation in this context is defined as marking an artifact as obsolete to warn against use in the
future so that an artifact may be phased out either entirely or for a specific use case. Deprecation
indicates that future use should be avoided, typically because the artifact has been superseded.
1.3.2 Deprecated Artifact
An artifact, as defined in the scope of the IHTSDO Deprecation Policy, which has been deemed no
longer suitable for new implementation or future use. The artifact may continue to exist to provide
historical information and backward compatibility. An artifact may be deprecated for many reasons
(see examples in 2.1 Reasons for Deprecation). The reason, appropriate use and any continued or
IHTSDO Deprecation Policy
Page 1 of 5
discontinued maintenance support of the Deprecated Artifact by IHTSDO will be declared with the
Announcement of Deprecation. Artifacts can be deprecated with support or without support (see next
definitions).
1.3.3 Artifact Deprecated With Support
A designation given to an IHTSDO Artifact that has been deprecated but continues to be supported by
IHTSDO for a specified period of time. The detail of the support will be provided with each Deprecated
Artifact.
1.3.4 Artifact Deprecated Without Support
A designation given to an IHTSDO Artifact that has been deprecated and is no longer supported by
IHTSDO, i.e. IHTSDO no longer provides any maintenance or updates.
1.3.5 Inactive
Deprecation should not be confused with the term inactive. An Inactive Component, Inactive Concept
and Inactive Description, terms used in the SNOMED CT file History Mechanism, are defined in the
IHTSDO Glossary.
1.4 Audience
This policy document will be of interest to anyone who is using and implementing IHTSDO artifacts
and all those who are interested in knowing how these Artifacts are deprecated. It also provides
direction for those who produce, maintain and update Artifacts. This includes:
• IHTSDO members
• IHTSDO Organization
• National Release Centers
• Affiliate Members including vendors and systems integrators
• Other Users
1.5 Scope
IHTSDO and its predecessors have produced a wide range of documents and products over time to
respond to the needs of SNOMED CT developers and users.
The scope of the IHTSDO Deprecation Policy includes any artifact that has completed the formal
process defined in the Development, Approval, Maintenance and Review of IHTSDO Technical
Reports, Guidelines and Standards. Examples of artifacts include: the SNOMED CT Technical
Implementation Guide; the SNOMED CT Editorial Guide; and the SNOMED CT User’s Guide. Other
types of assets or terminology products are Release format, antecedent versions, Hierarchies,
Attributes, Reference set, maps, usage of attributes in particular hierarchies, values usable for
particular attributes, release modules, quality assurance rules in the work bench and harmonization
agreements.
The scope and description of the artifact being proposed for deprecation will be clearly stated.
This Policy is intended for deprecation of International Artifacts. Member countries are encouraged to
use a similar policy and process to deprecate their country specific IHTSDO related artifacts. IHTSDO
may, over time, agree with Member countries criteria for when the same processes should be followed
by Member countries, particularly where safety is the cause of the deprecation.
IHTSDO Deprecation Policy
Page 2 of 5
Artifacts being changed or made inactive through the Content Development Process and the Request
Submission Process are not required to go through the Deprecation Process in addition to these
processes. Examples include SNOMED CT components, concepts, descriptions and relationships.
The scope of this policy does not include software tools to support editing, request for change,
translation and mapping. It is recommended that policies on software version management and
deprecation must be defined, adopting similar policies found in this Policy and managed alongside this
policy over time.
The scope of the policy also does not include artifacts not approved or in final release versions e.g.
beta release or technology preview status.
The scope of this Deprecation Policy will be revisited at the 2 year review based on experience and
usage. This should lead to a more defined list of artifacts in and out of scope.
2 Deprecation Considerations
While the concept of deprecation of an Artifact can take many forms, the policy and the process for
deprecation should focus on two aspects of deprecation:
•
Reasons for deprecation of an artifact; and
•
Determination and communication of the support of the deprecated artifact.
2.1 Reasons for Deprecation
The deprecation of an artifact specifies to users that it should no longer be used. It is important that
developers, maintainers and users understand the reason why it should no longer be used (identified
as part of impact assessment). Simply put, all deprecations must have a clear reason that is central to
this policy.
Given the scope in Section 1.5, reasons for deprecation include:
•
•
•
•
•
•
The artifact has been replaced by a more current and relevant artifact (e.g. moving from one
SNOMED CT release format to a newer one; new methods for measuring conformance are found
to be better than previous methods);
The artifact contains an error (wrong, correction) (e.g. methodology error, content has been
classified incorrectly)
A safety issue has arisen and the artifact needs to be deprecated (e.g. deprecating a map file
because a technical error causes a map to point to the wrong diagnosis)
The artifact is extraneous (not used)
The artifact is a duplicate (e.g. duplicate QA rules)
The supplier of the artifact is no longer supporting or providing it.
It is clear that processes for Deprecation need to be in line with the size, impact, complexity and the
specific reason for deprecation, for example, deprecation due to a safety issue will need to be dealt
with much quicker than an artifact that is extraneous. Therefore the IHTSDO Deprecation Process
document outlines both fast track and longer, more detailed processes.
2.2 Declaration of Level of Support for a Deprecated Artifact
When an Artifact is deprecated, the level of support provided for that Artifact is discontinued in a
managed way. In many cases the support being provided cannot be changed on the same date that
IHTSDO Deprecation Policy
Page 3 of 5
the Artifact is being deprecated. A transition time period is necessary for those impacted to make their
own support or system changes and to migrate away from the product.
For the time period where support is provided following the deprecation, it will be considered to be
“Artifact Deprecated With Support”. Following this period of support, the Artifact will be considered to
be “Artifact Deprecated Without Support”. Not all artifacts will require support and may proceed
directly to “Artifact Deprecated Without Support”.
2.3 Deprecation Process
The IHTSDO Deprecation Process document describes both a fast track as well as a longer, more
detailed process for deprecation of artifacts. It describes how consultation with users will take place;
and who approves decisions along the Deprecation Process. Please refer to The IHTSDO
Deprecation Process document for details.
3 IHTSDO Deprecation Policies
1. A proposal for the Deprecation of an Artifact must have a stated reason for deprecation.
2. Deprecation will result when publication of a new release of an Artifact supersedes the existing
release.
3. Consultation on requests and proposals for deprecation of an Artifact will gather user feedback on: the
proposed date of deprecation and level and duration of support that will be provided by IHTSDO during
the deprecation period prior to withdrawal.
4. When an Artifact is declared to be Deprecated its status will be changed to “Deprecated
Artifact” and designated with either Artifact Deprecated With Support or Artifact Deprecated
Without Support. When documentation that refers to the Deprecated Artifact is updated, all
references to the Artifact, should be updated. This includes noting that it has been deprecated
along with the deprecation date and the level and duration of support.
5. The Deprecated Artifact, along with supporting documentation and deprecation documentation, will be
archived by the IHTSDO once it is no longer published..
Details of communication and documentation of the deprecation can be found in the IHTSDO
Deprecation Process document.
4 Process for Review of this Policy
The date for review of this policy will be identified clearly under history and agreed when the IHTSDO
Management Board approves the Policy and related process guidance and templates. The review will
be no later than 2 years after approval of the policy and related documentation but can be initiated at
an earlier interval if warranted (e.g. based on feedback)
The Quality Assurance Committee will undertake a review that will cover 3 areas:
1. Identifying whether there have been any issues arising from any specific deprecations and
whether these were the result of ineffective deprecation process
IHTSDO Deprecation Policy
Page 4 of 5
2. Contacting those who have used the deprecation for structured feedback
3. Issue an invitation to stakeholders about the effectiveness of the process from their perspective
i.e. did the process meet the needs of those having to deal with deprecated artifacts
4. Communicating back to the community on the feedback received.
IHTSDO Deprecation Policy
Page 5 of 5