| Page properties |
|---|
| Target release | 1.0 |
|---|
| Epic | |
|---|
| Document status | | Status |
|---|
| |
|---|
| colour | Green |
|---|
| title | DRAFTimplemented |
|---|
|
|
|---|
| Document owner | Rory Davidson |
|---|
| Designer | |
|---|
| Developers | |
|---|
| QA | |
|---|
|
...
- All of the existing functionality, and any relevant data, will need to be migrated
Requirements
...
...
...
...
...
The service must incorporate any legacy identifier functionality already implemented in the current ID service
...
...
|
| Title | User Story | Notes |
|---|
| | The service will provide publicly available REST APIs for multiple consumers (of which the IHTSDO's terminology server is one). | |
|
...
| | | The REST APIs should be documented using swagger and accompanying user and admin documentation into the confluence space. | |
|
...
| | | Consumers of the REST API will need to be authenticated based upon the IMS | | | |
|
...
| Consumers should be able to request for batches of new identifiers for components as well as for individual components | | | | 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. | |
|
...
| | | Identifiers should be generated sequentially, using the whitelist to bypass those identifiers already created | |
|
...
| | | The service should provide the ability to create the respective id format depending on what it is requested for (concepts, descriptions, extension concepts, etc...) |
|
...
...
| | | 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 | |
|
...
| | 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.)
| |
|
...
| | | 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’
| |
|
...
| | 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 |
|
...
| | | 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:
...