Page tree
Skip to end of metadata
Go to start of metadata

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

Email

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

  • No labels

9 Comments

  1. Rory Davidson when and how "Request work item grouping status" will be used?

    1. 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

      1. Rory Davidson Beside the status, what else do you expect to log for tractability purpose?

  2. We will get better performance if Request_work_Item_ID and RFC_Number are numeric values. Is it necessary to be Strings? 

  3. 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.

  4. 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.

    1. 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.

  5. 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

  6. Should we be able to see which user has changed the status through JIRA history?