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 and explanatory notes on the SNOMED CT International Medical Devices project and the resulting release files. This document covers the background of medical devices in SNOMED CT and the Global Medical Devices Nomenclature (GMDN) 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, WHO-FIC Collaborating Centers, vendors of electronic health records, terminology developers and managers) with an interest in medical device development 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 future basis of the medical device component of SNOMED CT and conversely for the GMDN Agency to use any 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. 

The SNOMED CT International Medical Devices Project

Overview of phases

The scope of the SNOMED CT International Medical Devices Project is the delivery of a concept model to support medical devices within SNOMED CT, and the continuous alignment of SNOMED CT with GMDN. Given the major scale of this scope, work has been broken down into 4 major Project Phases:

Project Phase 1: to deliver the first GMDN International Release in SNOMED CT and Proposals for the Medical Devices Concept Model. The medical devices content will to be updated (provided through the agreement with GMDN) in the six monthly SNOMED CT International Release. This will continue whilst the concept modeling developments are underway (phase 2) prior to the modeled data becoming fully available. 

Project Phase 2 Aim: to design and implement a robust SNOMED CT Medical Devices Concept Model, populated with SNOMED CT compliant and up to date GMDN preferred terms to levels of granularity similar to the drug product "Virtual Therapeutic  Moiety" or  VTM level, ready for implementation and development by domain experts and the broader IHTDSO member community at the end of this period. 

Project Phase 3 Aim: to refine the SNOMED CT Medical Devices Concept Model to greater levels of granularity using prioritized use cases and categories, with development following collaborative authoring best practice to target eight categories per year. 

Project Phase 4 Aim: To most cost-effectively maintain the SNOMED CT model in an established business as usual model.

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

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 are 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.

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). 

Updated GMDN content since November 2011

Active GMDN terms that were not categorized as In Vitro Devices (IVDs) and were not included in the November 2011 version of the GMDN database were considered for inclusion. Concepts that were not categorized as IVDs in 2011 and were flagged as such in 2013 were reviewed and considered in scope for inclusion (they are retained, even if they are now categorized as IVDs). Finally, GMDN terms that have changed their wording since 2011 were reviewed, and those that implied a shift in the original meaning were included in this release reflecting the November 2013 GMDN database status (the old terms were discarded and new SCTIDs were issued to avoid any potential ambiguity). 

As we're now in Phase 4 of the Project (Maintenance), the content in the July 2016 GMDN Simple Map package has been updated in line with updates received from GMDNA in the latest editing cycle.

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. As a result, the release includes three Language reference sets to enable browsing of preferred terms following US and GB spelling variants as well as original GMDN preferred terms. It is important to preserve the GMDN description as this is the name applied in the regulatory realm and therefore has a very clear separate use case from the en-GB and en-US reference sets. 

Effective date

All component states in the July 2016 SNOMED CT to GMDN Simple Map package have the value of effectiveTime field set to 20160731. 

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.