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

Item

Priority

Requirement description

Cat Type

1

1

The tool should ensure all necessary data (as defined in section 4.5) is provided in the submission by the use of mandatory fields for certain items.

Data Entry

2

1

Individual submissions need to be clearly associated with metadata in order to make it possible to sort or browse them. The metadata should include but not be limited to: source author and organisation, email address(es), SCT version info, date of submission, priority, who's been assigned to fix and when, fix status, date of last change in status etc.

Search

3

1

The tool should provide the ability to re assign a record to another owner

Workflow

4

1

Where a submission is relating to existing content, it must be possible to state this in the submission including reference to individual concepts, groups of concepts or derivatives.

Data Entry

5

1

Only the original requester/reporter should be able to retract a request, but when retracted, the request should not disappear from the log of all reports ever filed but simply be closed with final status 'retracted'.

Workflow

6

1

If a request is posted from a registered account:Confirmation email should be sent to all associated email addresses Automated update emails should be sent whenever the reported issue has a change of status. It should be possible to specify whether such emails should be human readable (e.g. a simple notification that something has changed, and containing a URL to a page explaining what has changed) or machine readable (e.g. something that could be processed by a subsidiary national release centre application). This function must have an override facility This triggers for update emails must be configurable

Notifications

7

1

The tool should provide the ability to log times at which state of a request changed

Audit

8

1

There must be a facility to refer back to requester for clarification

Workflow

9

1

There should be the ability to record comments on change of status of a Request

Workflow

10

1

There is a requirement for acceptance of the resolution and or closure of a Request by the requestor

Workflow

11

2 (a manual process may be required to support initially)

There must be a facility to refer onward to an appropriate source of authority (e.g. Content coordinator, senior member of modelling team, relevant clinical specialist, Chief Terminologist, Content Committee, etc.)

Workflow

12

2

The tool must provide the ability to structure a submission to include the following (the full level of detail would not be required for each request)For new submissions proposed representation consisting of: Fully Specified Name; Terms and other designations in one or more languages (include language usage information – i.e. as in Descriptions and language RefSets); Defining Relationships. For proposed changes Representation of the component before the proposed change (for reference); Proposed representation after the change.

Workflow

13

2

The tool should enable the submission of bulk changes using the IHTSDO specified Standard format. Each entry within any bulk submission will be allocated an individual GUUID for tracking purposes. There must be a mechanism to submit a large number of submissions and to track the components of the submission in the same way as individual submissions.

Bulk Submission

14

2

The tool must include the ability for screening of submissions to group them by completeness, quality and content.

Reporting

15

2

The tool should provide the ability to link to a pre-release version of an added ConceptId or changed

View Changes

16

2

The tool should provide the ability to log and attach plans and other associated documentation to a Request

Data Entry

17

2

The tool should provide the ability to raise a work request as a result of an issue / request and to link the records

Workflow

18

2

An option is required to link or group existing related submissions or to add a new submission to an existing linked group

Clarify

19

2 (a manual process may be required to support initially)

There must be a facility to refer onward to an appropriate source of authority (e.g. Content coordinator, senior member of modelling team, relevant clinical specialist, Chief Terminologist, Content Committee, etc.)

Workflow

20

3

The tool should enable the provision of links to reference materials supporting the request for change.

Data Entry

21

3

Text fields must allow simple text formatting and wherever possible not be restricted in terms of maximum number of characters.

Data Entry

22

3

Any Member or Partner organisation should be able to 'vote for' an already logged request in the hope of raising its urgency, rather than duplicating its content.

View Changes

23

3

Any affiliate who is not a Member or Partner organisation should be able to 'vote for' an already logged request in the hope of raising its urgency, rather than duplicating its content.

View Changes

24

3

Anybody should be able to register to receive the update emails relating to an individual request. It should be possible to identify any arbitrary group of related requests using the filtering mechanisms outlined above, and then register to receive update emails on all members of the group so identified.

Notifications

 

 

  • No labels

5 Comments

  1. Unknown User (michaelchu6) Rory Davidson question for point 22/23 above Does the IMS api response will tell whether the user is a Member of Partner organisation?

  2. Chris Swires may be able to help with this one.

  3. Rory Davidson We addressed this in HipChat earlier on, would you agree Phong Bui ?

    1. Sorry, my fault. HipChat not switched on! (smile)

    2. thanks this is resolved