dm+d Introduction

The dm+d is a dictionary of descriptions and codes which represent medicines and devices in use across the NHS. It provides:

  • the recognized NHS Standard for uniquely identifying medicines and medical devices used in patient care
  • clear, consistent recording and communication of information relating to medicines and devices used in patient care
  • consistency in how medicines and medical devices are expressed through a robust published Editorial Policy

More on the dm+d dictionary is delivered through a partnership between NHS Digital and the NHS Business Services Authority (BSA). In this partnership BSA delivers Dm+d as a stand-alone product with SNOMED CT identifiers to NHS Digital for integrating it with the rest of SNOMED CT including the clinical terms.

Snow Owl’s dm+d Feature

Snow Owl’s dm+d Feature facilitates this integration by providing support for the following main process steps:

  1. Validation
  2. Transformation
  3. Authoring
  4. Review
  5. Release


As part of the pre-processing, the dm+d archive received from BSA is validated. The results of the validation process is written into a dedicated log file and can only pass or fail. In case of any failed results no further processing is allowed. The types of validation steps executed:

  • File validation – checks the number and types of the files within the archive
  • Schema validation – checks whether the provided XML files conform to their XSD schemas
  • Model validation – checks the references between the drug model classes (no checks for invalidated references)
  • Supporting data validation – checks for references between the drug model classes and the their referenced supporting data (Ingredients, Forms, etc.)


The transformation process is part of the pre-processing of the validated dm+d archive. The process starts with computing the differences between two consecutive dm+d archives to categorize the changes as:

  • Added
  • Added as Invalid
  • Modified
  • Invalidated
  • Replaced

Once the differences are calculated and written into a set of delta files, the RF2 generation process is executed. The generation process creates a standard RF2 archive that can be imported into Snow Owl. Parsing the terms for the Developer’s Toolkit is an integral part of this generation process. Important to note that the generated RF2 archive contains two additional reference sets one to hold the components that require manual authoring while the other to manage the Developer’s Toolkit parsed terms.


The generated RF2 archive is need to be imported into Snow Owl for further processing. As the first step a new and dedicated task needs to be created to provide workflow support for the imported dm+d content.

dm+d perspective

A perspective defines the initial set and layout of views in Snow Owl. The dm+d perspective combines the views that are commonly used while working with the dm+d components. The dedicated dm+d perspective can be accessed by choosing Window > Open Perspective menu or by clicking on the dm+d perspective toolbar button if visible.

dm+d editor

After activating the task the dm+d content had been imported to, a dedicated editor can be opened for further manual authoring. The editor is populated with unpublished components and components that have not been authored. This means that unauthored yet already published components will be present in the editor.

To open the dm+d Editor select the Open dm+d Editor menu item under the Tools main menu. The dm+d editor organizes the components to be manually edited on five editor tabs:

  1. VTM – for the new and replaced VTM concepts to set a parent
  2. VMP – for the new and replaced orphan VMP concepts to set a parent
  3. AMP – for the new and replaced AMP concepts to set the Trade Family
  4. Supporting Data – for the new and replaced Form, Route or Unit of Measure concepts to set a parent
  5. Bonus terms

dm+d editor

Each table within the different editor tabs contains rows that represent a component that require manual intervention. Each row has a status cell (X/√) where the changes can be confirmed by the author. With the exception of the Bonus terms tab, the editor tabs display concepts to be parented. By clicking on the parent cell, a new parent can be picked using the invoked Quick Search widget. The content of the picker widget can be restricted by typing into it’s text field. Alternatively, parent concepts can be dragged into the table from other views that display concepts such as search results or the SNOMED CT navigator. Once a new parent is selected, the row automatically changes to authored. Already authored items can be filtered from the table by clicking on the Hide authored items toolbar button. During the authoring process, the progress can be saved at any time by either clicking on the save icon/menu item or by pressing CTRL-S on the editor. Double-clicking on a concept opens the standard concept editor.

During the authoring process, the editor validates the content being edited and displays the validation messages within the editor’s header area. The current validation rules are:

  • Missing parent – check whether the component has been parented or not
  • Matching semantic tag – checks whether the component’s semantic tag matches the top-level concept’s semantic tag
  • Un-parseable bonus file term – checks whether the term has been parsed or not (first parsed term matches entire FSN)

Note: Internally, the content of this editor is backed by two simple map type reference sets:

  • Parenting mapping set – for components that require manual parenting
  • National Health Service dictionary and devices parsed terms- for parsed bonus terms


As the dm+d content is changed manually via the editor, the last step of the authoring process is running the dm+d ‘classifier’ to inherit certain relationships from the parent concepts. The ‘classification process’ can be invoked via the Classify dm+d menu item located under the Tools main menu. As the process traverses the entire dm+d graph, this is a long running operation running on the server with it’s progress traced within the Remote Jobs view.


Once the manual authoring is completed, the task containing the work is assigned to a reviewer as the next step in the workflow. A reviewer can validate the results of the manual authoring process and promote the content into the repository upon successful confirmation. Alternatively, the task is re-assigned to an author with the issues communicated as task comments.


Once the reviewed content is promoted into the main repository, the dm+d components are ready to be released using Snow Owl’s RF2 export wizard.

Workflow improvements

Sequential review

Once the reviewer is done reviewing, another reviewer can be assigned by clicking the Request another review button in the task editor. Users can specify another reviewer by selecting from the list where only valid users are offered. Only users with promotion role are considered as valid users for second reviewer.

The selection of another reviewer is optional if the first reviewer already has promote rights. In that case he/she can simply proceed with the task promotion. This enables both single review and dual sequential review workflow scenarios.

Another reviewer

Selecting module at task creation

After selecting SNOMED CT as the code system on the second page of the task creation, a new field shows up offering to specify the module of the task, so users can tag the task with the appropriate SNOMED CT modules to define and refine the scope.

The number of specified modules is optional. After adding a module a red X shows up, so that it can be removed in case it is not needed.

Selecting module

Query tasks by module

Tasks can be searched by specified modules after selecting SNOMED CT as code system in the task query dialog. The number of specified modules is optional. After adding a module a red X shows up, so that it can be removed in case it is not needed.

Query task by module

No commit comment

No commit comment is asked when working on a task. Commit comments are automatically generated using the task ID and the Summary.

Administrators committing changes onto the MAIN repository are still prompted to enter a commit comment for their changes.