Target release1.0
Epic 
Document statusIMPLEMENTED
Document owner

Rory Davidson

Designer
Developers 
QA

Goals

  • To replace the existing SCT identifier functionality used by the existing IHTSDO and Managed Service release processes with a component identifier service which scales to allow the IHTSDO and external stakeholders to request new identifiers and release existing identifiers, amongst other functionality listed here, over an authenticated REST interface

Background and strategic fit

This is needed to provide a scalable service which will provide a single source of truth for SCT component identifiers, accessible by other organisations to be used as part of their existing release processes.

Assumptions

  • All of the existing functionality, and any relevant data, will need to be migrated

Requirements

  Title User Story Notes
1   The service will provide publicly available REST APIs for multiple consumers (of which the IHTSDO's terminology server is one).  
2   The REST APIs should be documented using swagger and accompanying user and admin documentation into the confluence space.  
3   Consumers of the REST API will need to be authenticated based upon the IMS  
4   Consumers should be able to request for batches of new identifiers for components as well as for individual components  
5   The service will provide the ability for a consumer to provide a single or list of identifiers already released (by anyone) so that these can be added to the whitelist within the service.  
6   Identifiers should be generated sequentially, using the whitelist to bypass those identifiers already created  
7   The service should provide the ability to create the respective id format depending on what it is requested for (concepts, descriptions, extension concepts, etc...) For reference see - http://ihtsdo.org/fileadmin/user_upload/doc/en_us/tig.html?t=trg2main_sctid_partition
8   The service should provide the ability to configure the formats without changing any source code or data structures for potential future products  
9   The service should be able to store a provided system id (like the WB and uuid at the moment) against the allocated id for future reference  
10  

The service should have the ability to assign IDs to all kinds of artefacts 

  • It can be extended if necessary for different formats (for LOINC, ATC, etc.)
 
11  

The service will allow consumers of the service to reserve blocks per user/module/namespace

  • Reservation can expire if not used after a determined period
  • Identifiers can be marked up as ‘free/reserved/assigned’
 
12   CTV3 and SNOMED legacy identifiers are to be generated for every new SNOMED CT concept identifier, and a map among them is to be maintained. This will become unnecessary in time, but we foresee tat we will require these legacy identifiers for several years to come
13   A simple admin UI will be needed to manage the service. This will only be available to IHTSDO staff.  

Questions

Below is a list of questions to be addressed as a result of this requirements document:

QuestionOutcome

Not Doing