...
| # | 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 | ||
| 45 | Ability to 'whitelist' artefact ids that have are already released (by anyone) | ||
| 56 | Sequential/linear id generation, using the whitelist to bypass those identifiers already created | ||
| 67 | Ability create the respective id format depending on what it is requested for (concepts, descriptions, extension concepts, etc... even other coding systems possibly in the future) | ||
| 78 | Ability to store a provided system id (like the WB and uuid at the moment) against the allocated id for future reference | ||
| 89 | Ability to assign IDs to all kinds of artefacts
| ||
| 910 | Can reserve blocks per user/module/namespace
| ||
| 1011 | 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 | |
| 1112 | A simple admin UI will be needed to manage the service. This will only be available to IHTSDO staff. |
...