Introduction

The SNOMED CT terminology provides a common language that enables a consistent way of indexing, storing, retrieving, and aggregating clinical data across specialties and sites of care. The International Health Terminology Standards Development Organisation (IHTSDO^®) maintains the SNOMED CT technical design, the content architecture, the SNOMED CT content (including the concepts table, the descriptions table, the relationships table, a history table and ICD mappings), and related technical documentation. 

This document is intended to give a brief description, background context, explanatory notes on the SNOMED CT International Medical Devices project and the resulting Release package, which is now published every 6 months. This document covers the background to the collaboration between IHTSDO and Global Medical Devices Nomenclature Agency (GMDNA) and goes on to cover the consequent release artefacts. It is not a detailed technical document of SNOMED CT, GMDN or the SNOMED CT International Medical Devices release. Nor does it seek to provide an editorial policy for medical devices.

Audience for this document

This document should be read by all those (National Release Centers, vendors of electronic health records, terminology developers and regulators) with an interest in the usage of medical device content in SNOMED CT and its linkage with GMDN. 

Background

The decision of the joint IHTSDO Management Board and General Assembly in October 2010 was to work towards a Cooperation agreement with the Global Medical Devices Nomenclature Agency (GMDNA), owners of the Global Medical Devices Nomenclature (GMDN), with the intention that the content of GMDN be integrated with the basic terminological content of the medical devices component of the International Release of SNOMED CT. In April 2012 the culmination of discussions between the IHTSDO and GMDNA was the signing of a cooperation agreement which now permits the IHTSDO to use the content of GMDN as the basis of the medical device component of SNOMED CT and conversely for the GMDN Agency to use SNOMED CT medical device content to inform GMDN development. The collaboration is consistent with the aims of both organisations to minimize duplication of effort and support international harmonization. 

Scope and Purpose of the collaborative work

The scope of the SNOMED CT International Medical Devices project was the delivery of a concept model to support medical devices within SNOMED CT, and the continuous alignment of SNOMED CT with GMDN.  This was managed in phases. We are now in the business as usual (maintenance) phase of the continuous alignment of SNOMED CT with GMDN. We are in the development phase of the delivery of a concept model to support medical devices within SNOMED CT.  

Under the terms of the Cooperation agreement between the IHTSDO and the GMDNA, only active GMDN Preferred Terms were under consideration for inclusion in the SNOMED CT International Release. Of these approximately 11,000 were In Vitro Diagnostic medical device (IVD) terms. These terms are authored to a different level of granularity than the rest of the GMDN content and set them apart in this difference. The level of detail they hold was discussed and the IHTSDO made the decision to not include them in SNOMED CT until a compelling use case for the IVD terms is identified, from the perspective of SNOMED CT users.

Release content

Overview

The medical devices derivative content is released under a project-specific module (466707005|SNOMED CT Medical Devices module) with component identifiers that are within the main IHTSDO (International Release) namespace. The content links into the main International Release Physical Object hierarchy, and therefore all the fully specified names have a ("physical object") semantic tag. All the concepts are primitive i.e. no modeling beyond the subtype relationships, and the hierarchical organisation is based on existing GMDN groupings ('collective terms'). 

Content detail

Each SNOMED CT new concept has at least 2 descriptions (Fully Specified Name and Synonym). Following International Edition editorial policies, GB and US spelling variants were generated as necessary and the preferences reflected in the corresponding language reference sets. A third reference set (608771002|GMDN language reference set) is included to enable the identification of the original GMDN term, as in a small number of cases minor editing has been necessary to align terms to SNOMED CT International Edition naming conventions (i.e. acronyms included in original GMDN terms were expanded in the FSNs derived from them). 

To enable the tracking of the relationship between SNOMED CT concepts and GMDN terms across releases, the preliminary linkage table has been replaced by a simple map reference set between SNOMED CT concepts and GMDN terms (467614008|GMDN simple map reference set). 

From July 2018 onwards, SNOMED International will also process modified and obsolete concepts, rather than just new and inactivated.  Modified GMDN codes which require a new concept to be authored will subsequently be flagged as "no target". Obsolete GMDN codes will have the GMDN target map flagged as "no target".

Language preferences

The original English language used to represent GMDN terms is 'European English' and therefore spellings conform to US derivative in some instances and GB in others. GMDN terms also include spellings with US and GB variants in the same description. New descriptions were created to align content with International Edition practices, including the expansion of acronyms in FSNs. 

Effective date

The content in the January 2021 GMDN Simple Map package has been updated in line with updates received from GMDNA in the latest editing cycle.  All component states in the January 2021 SNOMED CT to GMDN Simple Map package have therefore been assigned the value of 20210131 in the effectiveTime field. 

Technical Notes

RF2 package format

The RF2 package convention dictates that it contains all relevant files, regardless of whether or not there is content to be included in each particular release.  Therefore, the package contains a mixture of files which contain both header rows and content data, and also files that are intentionally left blank (including only a header record).  The reason that these files are not removed from the package is to draw a clear distinction between:

1. ...files that have been deprecated (and therefore removed from the package completely), due to the content no longer being relevant to RF2 in this or future releases, and 
2. ...files that just happen to contain no data in this particular release (and are therefore included in the package but left blank, with only a header record), but are still relevant to RF2, and could therefore potentially contain data in future releases.

This allows users to easily distinguish between files that have purposefully been removed or not, as otherwise if files in option 2 above were left out of the package it could be interpreted as an error, rather than an intentional lack of content in that release.