Actors:

  • HL7 Community Member (Requestor) 
  • HTA Member (HTA)

Step 1: Creating the request (Step 3(b) from the draft process)

  • Requestor goes to the HL7 Terminology Authority JiraProject (perhaps at the link: https://jira.hl7.org/projects/HTA)
  • Requestor clicks on the "Create" button at the top to create an issue
  • The Create issue pop-up page displays the following:
    • Project: (value defaults to HL7 Terminology Authority)
    • Issue Type: A pull down of issue types. The only value (and the default) should be "External Code System Owner Engagement" 
    • The field for the specific issue (note, there will only be a default page for these - no advanced one required)
      • "Requestor":
        • Mandatory: Yes
        • UI: Pull down box
        • Values:
          • All users registered in Jira(defaults to the currently logged in user)
        • Guidance for use: ""The individual making this request"
      • "Requestor Group":
        • Mandatory: No
        • UI: Pull down box with search text
        • Values:
          • All HL7 Work Groups, Projects and Governance Teams (e.g. ARB, HTA, etc.)
        • Guidance for use: ""The HL7 Work Group, Project ot Team making this request"
      • "Request type": 
        • Mandatory: Yes
        • UI: Pull down box
        • Values:
          • "Use of External Code System with FHIR" (default)
        • Guidance for use: The type of request. 
        • Notes: In future, there may be different additional types of requests.
      • "Short request title':
        • Mandatory: Yes
        • UI: Text input box
        • Value: Free text
        • Guidance for use: A short title for the request.
      • "Request detail':
        • Mandatory: Yes
        • UI: Multiline text area
        • Value: Free text
        • Guidance for use: The full request in as much detail as possible.
      • "Related Code System": 
        • Mandatory: Yes
        • UI: Text input box
        • Value: Free text
        • Guidance for use: The name of the Code System which this request pertains to.
      • "Required for":
        • Mandatory: Yes
        • UI: Text input box
        • Value: Free text
        • Guidance for use: What the requested artefacts will be used for (e.g. a standard, an implementation guide, etc)
      • "Due diligence performed":
        • Mandatory: Yes
        • UI: Multiline text area
        • Value: Free text
        • Guidance for use: What due diligence checks have been performed (e.g. enquiring with the HTA, checking the FHIR CodeSystem Registry, etc).
      • "Attachments":
        • Mandatory: No
        • UI: Jirafile attachments
        • Value: Files
        • Guidance for use: Allows the Requestor to attached relevant files.
      • Once completed (with all mandatory fields populated), a new Jira issue is created and the HTA notified via email.
    • The issue should have the following work flow statuses:
      • Submitted(immediately after submission)
      • Information-Required (once the HTA have completed step 4 in the draft process and determined that more information is required from the Requestor to continue processing the request)
      • Engagement-Required(once the HTA have completed step 4 in the draft processand determined that the request does ineed require engagement with the external code system owner)
      • No-Engagement-Required(once the HTA have completed step 4 in the draft process and determined that the request can be addressed without engagement with the external code system owner)
      • Can-Engage (once the HTA have completed step 5 in the draft process and has obtained all the information required to commence engagement with the external terminology owner)
      • Initial-Request-Letter-Sent(once the HTA has completed step 6 in the draft process and sent the initial request letter to the external code system owner)
        • A workflow to add initial request letter to the Jiraissue should be supported
      • Positive-Response: (once the HTA has received a response to the initial request letter from the external code system owner indicating a willingness to work with the HTA)
        • A workflow to add the response to the Jiraissue should be supported
      • Negative-Response:(once the HTA has received a response to the initial request letter from the external code system owner declining to work with the HTA)
        • A workflow to add the response to the Jiraissue should be supported
      • No-Response:(once the deadline for a response to the initial request letter from the external code system owner has occurred)
      • Resolved: The final status


  • The issue should have the following options for a Resolutionvalue once the issue status is Resolved:
    • Request resolved with external code system owner;
    • Request resolved without external code system owner:
  • The issue should have a Text Area value for a ResolutionArtefacts value once the issue status is is Resolved. This would allow the HTA to summarise any artefacts resulting from fulfilment of the request e.g. a System URI.
  • Once submitted, only the HTA should be allowed to make changes to the statuses.
  • No labels