Page tree
Skip to end of metadata
Go to start of metadata




The authoring workflow on this platform is a departure from the previous workflow which you may have been working with in the IHTSDO Workbench.

The IHTSDO Workbench provided a single view and storage for all the work being done within an authoring cycle. This has been beneficial in allowing users to view all the work being done at a particular point in time, but it has also meant that authoring is done on top of unfinished work and has restricted the ability to make large changes to the terminology without impacting other authors at the same time.

The new authoring platform provides an approach based around branches, and moves away from the single central repository approach of the Workbench.

Workflow Two



The core idea behind the new workflow is that all content project authoring should take place in a dedicated project branch instead of the release branch, commonly known as the MAIN branch. This encapsulation makes it easy for multiple authors to work on a particular content project without disturbing the main release. It also means the MAIN branch will never contain broken terminology and can be released at any moment, which is a huge advantage for continuous releases of SNOMED CT.


Like the IHTSDO Workbench, this approach still uses a central repository, and MAIN still represents the official release history. But, instead of making changes directly on the MAIN branch, as in Workbench, a new branch is created when there is a new content project, called a project branch, providing a part of the repository for work to be done on that particular project, without impacting other projects. These project branches are also intended to never contain broken terminology and therefore can be released as technology previews in isolation from the main release. 

Therefore, in order to protect the project branch, any new authoring is done on task branches.


As an authoring task is identified a task branch is created from the specific content project. A task has no restriction on the number of concepts that can be worked on during a task, but there are a number of considerations to take into account:

  • how much can be reviewed
  • tasks should not be kept open, or in progress for too long (no more than a few weeks)

Every time you start working on a new task that has been allocated to you, you should create a new branch for this task.  As you only have a single long(always)-running branch in your repository, MAIN, all new project branches are based off of this MAIN branch. 

In the meantime, it might be that new content gets integrated into MAIN from other projects while you're still working on your project. It's both recommended and simple to merge new stuff often from MAIN into your project branch. This ensures that you're staying up-to-date - and thereby reduces the risk of merge conflicts that come with large project promotions.

The golden rule that comes with this workflow: any content that gets promoted as part of a project into MAIN must be complete. This means reviewed, classified with the necessary quality assurance having been done.




  • No labels