...
| # | 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 | Ability The service will provide the ability to 'whitelist' artefact ids that have are already released (by anyone) | |||||
| 6 | Sequential/linear id generationIdentifiers should be generated sequentially, using the whitelist to bypass those identifiers already created | |||||
| 7 | Ability The service should provide the ability to 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) | ) | ||||
| 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 | 8 | Ability to store a provided system id (like the WB and uuid at the moment) against the allocated id for future reference | |||
| 910 | Ability The service should have the ability to assign IDs to all kinds of artefacts
| |||||
| 1011 | Can The service will allow consumers of the service to reserve blocks per user/module/namespace
| |||||
| 1112 | 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 | ||||
| 1213 | A simple admin UI will be needed to manage the service. This will only be available to IHTSDO staff. |
...