Target release 0.1.0 Epic Document status Document owner Emily Wang Designer Robert Turnbull Rory Davidson Emily Wang Developers Kai Kewley Chris Swires Ashley Hickey QA Emily Wang Steve Archbold Robert Turnbull

Goals 

Background and strategic fit

Meeting SNOMED CT international requests plays a critical role in providing the necessary service to requesters with many member countries and internal authors realizing they need to improve the request process. The Request Management process would be designed in such as way that it would be a formal process is used to manage each request related to authoring from both external and internal. The request management provides:

• Single a central point for accepting, managing, tracking, and fulfilling all requests (ad-hoc requests, batch requests, concept model change, planned content project, and promoted content).
• Catalog of standardized requests
• Automated and consistent process for template-based authoring and batch editing
• Ability to rapidly requests to support a dynamic business environment
• Executive dashboard and service metrics

Assumptions

• Request management is only for content authoring request management. Mapping request management is not included in this project.
• Users on request management service have been logged-in via Identity Management Service (IMS).

Requirements - Separate project -not done

#	Title	User Story	Importance	Notes
1	Creation and monitoring of requests by those who submitted them	As a requester, I want to create and track the progress of the requests I submitted.		Additional considerations or noteworthy references (links, issues)
2	Management of requests as a manager	As a request manager, I want to manage projects and relevant requests
3	Management of requests as an author	As an author, I want to manage requests assigned to me so that I can can change the status of the request when I need.
4	Management of request as a requester	As a requester, I want to manage the requests submitted by me so that I can follow up with author who is assigned to my tickets
5	Sending an e-mail message to the requesting user when the request status has been changed	As a requester/an author, I want to receive emails of updates on the request submitted by me/the request assigned to me
6	Advanced and efficient search tool	As a requester/an author, I want to search requests by text, ID, etc.
7	Integration to other authoring processes in Orchestration Service	As a user, I want to integrate the request management service with other services.
8	Providing increased visibility into request fulfillment (track request status from entry to completion)	As a user, I want to see all requests I have permission to access.
9	Providing an online catalog that lists all services available to a requester (add/edit/retire concept, add/edit/retire description, add/edit/retire relationship, etc.)	As a requester, I want to see a catalog that lists of all types of requests I can submit, so that I can submit the request by using provided request format.

Status in workflow of request-concent

New: when a request is submitted, it will be in this state until accepted by an author for authoring. 

Accepted: this state is intended to let the requestor know the request meets the criteria to be in scope for the international release of SNOMED CT.

Under authoring: when an author starts working on a request, it will enter this state. 

Pending clarification: when an author needs to clarify the finer detail of a particular request, it will enter this state. When a request for clarification to a requestor is not answered within 12 weeks from the date the clarification is requested, then the request can be closed with a state of Rejected.

On hold: when a request for a specific project, which requires at least two member countries request the same concept, it will be in this state until the second member submitted the same request.

Approved: once the edit has been made and approved for release, it will enter this state.

Rejected: if a request is out of the scope of international release SNOMED CT, it will enter this state. 

Withdrawn: if the requestor want to withdraw the request, it will enter this state. However, a request cannot be withdrawn after it is under authoring. At this point, request will be closed.

Appeal: if a request is rejected by an author, and the requestor appeal it, it will enter this state. The authoring team will carefully review appealed request and the rationale provided and will make a final decision.

Appeal rejected: if a request is rejected and appealed, and author decides to reject it again, it will enter this state. Appeal will not be possible on this request after it entered this state. In order to ask author to reconsider their decision, a new request needs to be submitted by requestor.

Closed: if a request is rejected and no appeal, it will enter this state. Another case is after released the content change(s) in an accepted request, it will enter this state.

User interaction and design

Case 1: Request is accepted and has no need to clarify with requestor or put on hold for any reason.

Case 2: Request needs to be clarified with requestor then accepted.

Case 3: Original request is rejected but requestor appeals the request and appealed request is accepted.

Case 4: Original request is rejected but requestor appeals the request and appealed request is rejected.

Case 5: Original request is rejected after it is under authoring but requestor appeals the request and appealed request is rejected.

Case 6: Original request is rejected after it is under authoring but requestor appeals the request and appealed request is approved.

Case 7: Original request is rejected and no appeal.

Case 8: Request is withdrawn before accepted by project lead/author.

Case 9: Request is withdrawn after accepted but before it is under authoring.

Questions

Below is a list of questions to be addressed as a result of this requirements document: