A request for change should include the following items some of which would be completed by the change requestor:
Request Header
Item | Field | Description | Data Type | Priority |
1 | Approval_Authority_ID | The identifier assigned to the user in the role of Approval authority. The Approval authority is the user that verifies the need for the Request for Change (RFC) e.g. Member country or Partner organisation. The ID is assigned by the system upon registration by the user. | String | Required / Conditional |
2 | RFC_Number | The identifier generated and assigned by the Request Submission System upon receipt of the request. | String/ GUID | Required |
3 | Requestor_ID | The identifier assigned to the user in the role of submitter. The submitter is the user that actually logs into the system to enter or submit the Request for Change (RFC). The ID is assigned by the system upon registration by the user. | String | Required |
4 | Originator_ID | The identifier assigned to the user in the role of requestor. The requestor is the user that actually initiated and created the Request for Change (RFC) and may or may not be the same as the Requestor. Where the originator is known to the Request submission system the supporting information will be derived on entry of the Originator name. However if the originator is external to the system an ID will be generated on entry by the requester. | String | Required |
5 | Request_Date | The date the request is committed to the request system | Date | Required |
6 | Request_Status | The current status of the request. On initial entry the status will be set by the system to 'New' | String | Required |
7 | Request_Status_Change_Date | The date the status was changed. | Date | Required |
8 | Justification category | The business or logical need for the change(s). – drop down | String | Required |
9 | Target release | As defined by requestor in the request item 'target_release_date' | String | Optional |
Request Item
Item | Field | Description | Data Type | Priority |
1 | Artifact release_Version_Used | The version of the International release used to create the request | String | Required / Conditional |
2 | Affected_Component_ID | The identifier of the component that is the subject of the request. If a new concept request, this is the parent of the requested concept. For all other request types it is the ID of the existing component implicated by the request. | String | Required / Conditional |
3 | Proposed_FSN | For new concept requests, the proposed fully specified name | String | Required / Conditional |
4 | Proposed Synonym(s) | For new concept requests, or for new description requests | String | Required / Conditional |
5 | Proposed Attribute | For new relationship requests, the proposed linkage concept ID | String | Required / Conditional |
6 | Proposed target concept | For new relationship requests, the target concept | String | Required / Conditional |
7 | Proposed map target | For new / change to cross map, the proposed target concept | String | Required / Conditional |
8 | Proposed new map product target Terminology / Classification | For a new map product the proposed target Terminology or Classification | String | Required / Conditional |
9 | Proposed Refset definition | For new / change to Refset definition, the proposed refset 'intentional' definition or addition | String | Required / Conditional |
10 | Proposed Refset change detail | For new / change to Refset definition, the proposed refset 'intentional' definition or addition | String | Required / Conditional |
11 | Proposed Translation target concept | For new translation requests, the proposed concept / description to be translated | String | Required / Conditional |
12 | Proposed translation text | For changes to translation, the proposed translation text | String | Required / Conditional |
13 | Proposed new Translation product target language | For a new Translation product the proposed target language | String | Required / Conditional |
14 | Appeal_Date | The date an outcome appeal was submitted. | Date | Required / Conditional |
15 | RFC_Number | From Request_Header: The identifier generated and assigned by the Request Submission System upon receipt of the request. | String/GUID | Required |
16 | Request_work Item_ID | The identifier of the work item associated with the individual request (i.e. request batch) grouping of requests as a single work item | String | Required |
17 | Request_Type | The action required to fulfill the request (e.g. add new concept, move parent, add description, new map, change map, change refset, new refset etc.) – drop down | String | Required |
18 | Description | A detailed description of the requested change(s). | String | Required |
19 | Justification description | Free text supporting information to justification category in request header | String | Required |
20 | Rejection_Impact | The impact of a rejection of the change on the submitter | String | Optional |
21 | Target_Release_Date | The release version that the desired change would be implemented | Date | Optional |
22 | Submitter_Local_ID | The identifier used by the submitter to identify the request (e.g. local code) | String | Optional |
23 | Submitter_Local_Term | The term used as the source terminology for the request original request term / phrase | String | Optional |
Request Information
Item | Field | Description | Data Type | Priority |
1 | User_ID | The identifier assigned to the user upon registration. | String | Required |
2 | First_Name | The first name of the participant. | String | Required |
3 | Last_Name | The last name of the participant. | String | Required |
4 | Organization | The organization to which the participant belongs. | String | Required |
5 | Job_Title | The title or position the participant holds within the organization. | String | Required |
6 | Telephone | The telephone number of the originator of the request | String | Required |
7 | Telephone_Type | The type of phone number (i.e. home, business, mobile) | String | Required |
8 | The Email address of the Requestor | String | Required |
Request Status
Item | Field | Description | Data Type | Priority |
1 | Status | The status value for the entire request | String | Required |
2 | Status_from_Date | The date that the status was changed | Date | Required |
3 | RFC_Number | FK: from Request_Header table |
|
|
Request work item grouping status
Item | Field | Description | Data Type | Priority |
1 | Status | The status value for the request item | String | Required |
2 | Status_from_Date | The date that the status was changed | Date | Required |
3 | Request_Item_ID | FK: from Request_Item table |
|
|
Requesters
There are Member countries of the IHTSDO with National Release Centres (managing the Member extension and derivative products) and other Member countries without a National Release Centre, Partner Organizations both with and without content coordination groups, as well as affiliates operating outside Member countries entirely. All of these parties should legitimately be permitted to request changes via the IHTSDO Content Request System.
It is expected that National Release Centres and Partner organizations will play a key role in triaging requests for change arising from SNOMED CT users in their own country or jurisdiction. It is expected that requests to the IHTSDO will originate from the following groups, however this may not be an exhaustive list:
- Directly from National Release Centres or Member organisation
- Directly from Partner organisations and other Standards Development Organisations
- From Affiliate members outside a Member or Partner jurisdiction
- From clinical groups with an interest in refining and maintaining specific areas of the terminology via a Member or Partner organisation (or directly where outside a Member or \partner jurisdiction)
- From members of the research/academic communities via a Member or Partner organisation (or directly where outside a Member or Partner jurisdiction)
- End-user clinicians, delivering routine care via a Member or Partner organisation (or directly where outside a Member or Partner jurisdiction)
- Internal staff who recognise the potential for enhancement during the course of routine work
- System developers and the vendor community via a Member or Partner organisation (or directly where outside a Member or Partner jurisdiction)
- Internal staff (and partners such as external consultants) who are undertaking formal assignments and project work at the behest of the IHTSDO
- IHTSDO special interest groups and project groups
- Healthcare Service providers
9 Comments
Phong Bui
Rory Davidson when and how "Request work item grouping status" will be used?
Rory Davidson
This represents the status of a batch of items. The requirement would be to update a batch status when all of it's requests were processed/completed
Phong Bui
Rory Davidson Beside the status, what else do you expect to log for tractability purpose?
Tuan Nguyen
We will get better performance if Request_work_Item_ID and RFC_Number are numeric values. Is it necessary to be Strings?
Tuan Nguyen
Does each Request Item associate with one JIRA ticket? If so, Request Item must have properties to model that association, e.g. jiraTicketKey or jiraTicketID.
Tuan Nguyen
Hi Rory Davidson,
In RequestItem table, properties #7 to #13: does it mean that we should have Request Types: New/Change/Retire Cross Map, New/Change/Retire Refset and New/Change/Retire Translation?
If yes, please explain about Cross Map, Refset and Translation.
Rory Davidson
These are types of artefacts in and around SNOMED CT, although Translations can be ignored for now.
However, the system should make this 'generic' so we may add other types in the future. For now, we can include but it should be 'configurable' to add others.
Phong Bui
Rory Davidson regarding trace-ability do we need to track who has changed the status? As now it seems we don't have this info tracking yet
Rory Davidson
Should we be able to see which user has changed the status through JIRA history?