| Page properties | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 must incorporate any legacy identifier functionality already implemented in the current ID service |
| |
| 2 | The service will provide publicly available REST APIs for multiple consumers (of which the IHTSDO's terminology server is one). | ||
| 3 | The REST APIs should be documented using swagger and accompanying user and admin documentation into the confluence space. | ||
| 4 | Consumers of the REST API will need to be authenticated based upon the IMS | ||
| 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...) | ||
| 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
| ||
| 11 | The service will allow consumers of the service to reserve blocks per user/module/namespace
| ||
| 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:
| Question | Outcome |
|---|---|