Page tree

Project Scope Statement Pilot

Author: Joshua Procious, December 6, 2018.

Updated February 12, 2019









The intent of this test plan is to define the testing and expected result of the Project Scope Statement Approval Pilot on Confluence using the “Project Scope Statement” space ( ) and the Jira project “Project Scope Statemtent” ( https:/s/ ).

There are seven (7) roles in the Project Scope Statement approval, all of which will test the Project Scope Statement Index according to their role.

The Project Scope Statement was designed with the following in mind:

  • An effective tracking method must exist for PSS’s (Project Scope Statements) in their approval process, to include final approval.
  • The PMO (Project Management Officer) will be notified upon creation and publication of each PSS.
  • The most recent PSS template must be used by all PSS Creators (HL7 Project Scope Statement Template).
  • The PSS must undergo the follow workflow before final Approval:





There are seven roles in total for each PSS approval. In all roles, the user is expected to be a registered user.

  • Creators – Users within a workgroup that author and setup the initial PSS Template. This user will be responsible for “Watching” the PSS page.
  • Sponsoring WorkGroup – The initial group to review a PSS Draft. A vote (with link to PSS) will be necessary to decide approval.
  • Approval Groups – Co-sponsoring WorkGroups, FHIR Management Group, V2 Management Group, CDA Management Group, US Realm, Architecture Review Board
  • Steering Division – one of the follow four groups: Infrastructure Steering Division, Clinical Steering Division, Administrative Steering Division, Organizational Support Steering Division
  • Technical Steering Committee – group who will review and cast vote for the TSC
  • Project Management Officer – user who will conduct PMO updates
  • Administrator – user responsible for functioning PSS approval environment




Approvals will be conducted by a state transition of sub-tasks according to appropriate approving group.

The parent issue initially created in Jira will auto-transition dependent on the status of each approving groups (sub-tasks of parent issue).




Rejections will be conducted by the appropriate approval group. Rejections will signify that errors have occurred up until that point of review and will require significant modifications. Upon rejection, the PSS will pause in its approval process and the Sponsoring Workgroup will be notified. At this point, it is the Sponsoring Workgroup’s duty to review and correct errors noted on PSS and then transition the appropriate subtask back to “Ready for Review”. At this point the reviewing group will review changes made and transition their applicable sub-task to Approve. If changes were not adequate, the reviewing group may reject again and the process cycles until the reviewing group approves. 




Revisions will be conducted by any role who become aware of a point that needs attention in the PSS. Revisions will be relayed to the Creators by Inline Comments and “@mentioning” within the PSS itself. Revisions are not significant enough to use the rejection cycle of addressing issues as listed above.




Testing Process


  1. A Creator will author a PSS using the Project Scope Statement Index within the “Testing PSS Creation” Space and notify Sponsoring Workgroup. 
  2. The Sponsoring WorkGroup will review/approve/comment for revision.
  3. The PMO will receive notification and insert Project ID into PSS.
  4. The Creator will transition PSS to Group Approvals, notifying applicable groups.
  5. Approval Groups will review/approve/comment for revision.
  6. The Creator will monitor PSS for all approvals/revisions/comments and transition PSS to appropriate Steering Division Approval.
  7. The appropriate Steering Division will review/approve/reject/comment for small revision.
  8. Upon Steering Division approval the TSC will be notified.
  9. The TSC will review/approve/reject/comment for small revision.
  10. Upon TSC approval the PSS will enter the Published State.
  11. Upon the Published State being reached, all feedback will be reviewed by Administrator and handled (either brought to group for approval/implementation or direct implementation
  12. Administrator will compose a Post Test Review and present to testing group.


Creation Process

Approval Process



Specific Role Assignments


(those taking part in the PILOT)

Work Groups:

International Council

Infrastructure & Messaging

Implementable Technology Specifications

Electronic Services and Tools

Clinical Quality Information

Clinical Decision Support


Management Groups:

Architecture Review Board

Standards Governance Board


US Realm :

Dave Hamill

Steering Division :

Clinical Steering Division, Infrastructure Steering Division, Organizational Support Steering Division



Administrator : Joshua Procious



Help in Confluence