Project Proposal

Q: Does my project need a Project Proposal to start?

A:  If the project is developing a new specification or standard (i.e. a Release 1 version) that has never been balloted or published, it requires a Project Proposal to be accepted by the TSC BEFORE the Project Scope Statement is drafted.  If the project is updating an existing specification or standard (previously balloted or published), no Project Proposal is needed.  You also do not need to submit a proposal if you are re-activating a withdrawn project.

Q: How do I know the approval status of my Project Scope Statement or Project Proposal?

A:  Look up your project proposal or project scope statement in Jira, go to

In Jira, you can check the status of the individual sub-tasks for a Project Scope Statement by opening the PSS issue and reviewing the sub-tasks.

Q: How do I update the Project Proposal to identify the sponsoring Work Group?

A: See the How to Create and Review a Project Proposal

Project Scope Statements

Q:  Do I need to create a Project Scope Statement if my project isn’t going through the ballot process?

A: Yes, all projects need to have a Project Scope Statement completed and submitted to the HL7 PMO.  Project Scope Statements are the foundation for communicating project information.  They also serve as a tool for Project Facilitators to gather the right information to begin a project as well as track the project’s progress.

Q:  Do I need to create separate Project Scope Statements for each Implementation Guide or other support documents?

A:  A single PSS can indicate multiple deliverables for the standard being addressed, so, no, a separate PSS does not need to be created for each Implementation Guide or support document for that standard.  Simply identify all of the Implementation Guides and documents in the Product Information section that are to be produced for the project.

Q:  I have many related projects, should I include them all within one PSS or complete a PSS for each subordinate project?

A:  Creating a 'Master Project containing many subordinate projects' is discouraged.  Instead, multiple individual projects should be created, using the link functionality in Jira to refer to the other related projects.

Q:  The scope or objective of my project changed.  Do I need to create a new PSS?

A:  You may or may not have to as it depends on the change. Often times, the scope or objectives of a project may change during its lifecycle, perhaps due to regulatory changes or tying back to a different standard.  When the scope changes, it is preferred that a new Project Scope Statement NOT be created.  By keeping the same Project ID, the ballot site can readily point the same project ID to both STU and Normative ballots.  

If the change in scope or objectives is minor, it is recommended you export the PSS from Jira to Word.  Make the necessary changes to the Word document with track changes on.  Review with the sponsoring Work Group to get agreement on the changes.

Once you have reached agreement, go back into the Jira PSS and add a comment and include the edited Word Document.  You should email the Co-chair List and post on Zulip asking for feedback, in particular from the co-sponsoring Work Groups.  After a 2 week period, the modified PSS (Word document) can be forwarded to the TSC for approval. 

However, if the change in scope or objectives are major, the Project Facilitator should submit a new Jira Project Scope Statement, as much of the original information won’t accurately reflect what is being done anymore.

Q:  What defines a ‘major’ or ‘significant’ change in scope?

A:  Since ‘major’ and ‘significant’ are subjective terms, examples may provide better comprehension of a “major” or “significant” change to a project scope statement. 

A “major” or “significant change” in project scope includes the following:

  • Creating a new Release of a Normative or Informative artifact (excludes STU, refer to TSC Policy and Guidance to Work Groups on STU Updates vs. STU Ballots)
  • The Project End date extends by 24+ months
  • The Project Intent changes (i.e. the project changes from “Revising a Standard” to “Creating a Standard”)
  • The change in scope will result in an item that qualifies as ‘substantive change’ as defined in HL7 Essential Requirements Section 02.10.04. (Normative ballot)
  • The Realm changes from ‘Realm Specific’ to ‘Universal’ (since additional project resources may be necessary to support that change)
  • The deliverable's backwards compatibility changes from ‘Yes’ to ‘No’

Q:  What approvals are needed if I revise my existing PSS, say the project’s scope changes? 

A:  The same approval process should be followed whether it’s a new project or a scope change to an existing project.

When there is a major scope change to the project, the modified Project Scope Statement needs to go through the normal approval process (i.e. as if it were a new PSS -- the sponsoring WG, Co-Sponsors, Management Groups, US Realm, and the TSC). Approvals must meet the same ballot cycle deadlines as for a new project.  When the scope changes, it is recommended that a new Project Scope Statement NOT be created (use the same PSS as before).  Also, by keeping the same Project ID, the ballot site can readily point the same project ID to both STU and Normative ballots.  

Q: Who is the Project Facilitator

A: The Project Facilitator named in the Project Scope Statement serves as the Project Lead; the 'go to' person for the project who can answer questions regarding status, scope, objectives, issues, risks, etc. regarding the project.

Q:  I'm taking my project from STU to Normative or Informative to Normative, what should I do first?

A:  Prior to submitting a NIB, check the “Normative Notification” field in the Jira PSS.  A new sub-task will be created that must be completed which will trigger a notification to ANSI of a new standard coming.  It also begins a countdown clock where the project item(s) need to complete balloting within 18 months and then be published within 12 months.

Q:  Do I need to update the PSS if I discover after it’s approved that I need to coordinate ballots with other HL7 Work Groups?

A:  Yes, the PSS should be updated to include new co-sponsoring Work Groups or interested parties.

Q: I need to update a PSS that used an old template (MS Word or Confluence).  Should the updated PSS reside in Jira?

A: Having the updated PSS reside in Jira is preferable. To do so, create a PSS in Jira in a ‘Draft’ state.  Then email the HL7 Project Management Office (pmo@HL7.org) and Senior Applications Manager (joshua@HL7.org), notifying them of the draft PSS in Jira.  HL7 Staff can then move the PSS into a final state without the system issuing approval emails.
Note, if the original PSS used the MS Word template, contact the PMO (pmo@HL7.org) to obtain the latest MS Word PSS on file for the project.

Q:  Are there special considerations for STU ballots

A:  Refer to TSC Policy and Guidance to Work Groups on STU Updates vs. STU Ballots on the HL7 Essentials Confluence space for additional information on STUs

Q:  Should a Work Group create a new PSS when creating a new Release of a Standard?

A:  This is required for Normative and Informative artifacts only (STUs do not require a new PSS for a new release).  In most all cases, there will be a significant enough change in the newer Release of the Standard to warrant a new PSS.  New balloted products require a PSS, for example, adding ITS to an existing project creating a DAM (Domain Analysis Model).  Also, a new PSS helps for tracking and historical purposes, as a new PSS assists HQ in keeping a one-to-one relationship of standards to projects.

Q:  How do I add a co-sponsor to a PSS in Jira?

A: Go to How to Create a Project Scope Statement in JIRA for more information on how to add co-sponsors.

Q:  What ballot types are required to go through the project approval process?

A:  All ballot types (Comment-Only, Informative, Normative, STU) need to go through the project approval process, however, as identified in the Project Scope Statement, a single project can define ballot plans for multiple types of ballots for the project, for example, Comment Only > STU > Normative. 

Q:  Should a project remain open/active during its STU Test Period?

A:  Yes, it should.  This means that the project will continue to show up in the Searchable Project Database and on Project Insight reports.

Q:  How do I search/view HL7 Projects?

A:  There are two ways to view HL7 projects:

  1. The Searchable Project Database (http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm), located in the footer of the www.HL7.org Homepage.
  2. Confluence (https://confluence.hl7.org/display/PSS) – select PSS in Jira or PSS in Confluence.  NOTE:  Will not include PSS drafted in MS Word.  If you want a complete list of projects, use the Searchable Project Database.

Q:  How can I view projects which my Work Group is a co-sponsor?

A:  Look up your project using the Searchable Project Database (http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm), located in the Footer on the www.HL7.org Homepage).  Select your Work Group in the "Sponsor" dropdown field. The search results will reflect projects which your Work Group is sponsoring and co-sponsoring.

Q: What should I do if an approval group is unresponsive?

A: With the new Jira Workflow, the PSS Consensus Review period will remain open for 4 weeks.  At the end of 4 weeks, the PSS will transition to TSC Review.  If there are sub-tasks that have not been completed (for example, co-sponsoring Work Groups, etc), the TSC will work to get the tasks completed as part of their approval process.

Q: How do I know the approval status of my project?

A: Look up your project in the Jira Project Proposal/PSS project

Reaffirmation and Withdrawal of Specifications

Q: What is the difference between “retired” vs “withdrawn”?

A: Retiring is the term for a specification in HL7 that is " has no current or planned standards development activity within the community; which may no longer be in use, or which should not be considered for use."

Withdrawn is the ANSI term.

Q:  When withdrawing a published standard or a standard that has gone through balloting, does a PSS need to be created and go through the review/approval process?

A: ‘Withdrawing a standard’ refers to many things, such as closing a project in Project Insight whose specification has balloted, choosing not to extend a standard that has reached its 5 year end-of-life or identifying the need to sunset a standard. 

A Notice of Withdrawal of a Protocol Specification form must be completed, approved by the Work Group and submitted to the TSC for their approval, following   – Section 03.04.01.  This form is created by using the “Create...” dialog box at the top of Confluence.  Additional information is available on Confluence at Notice of Withdrawal of a Protocol Specification , especially the grid on page 2 of the Withdrawal Guidance Chart (doc), which lists the Action Items needed to withdraw your specification.

In most cases, a PSS will not need to be created.  Refer to the grid on page 2 of the Withdrawal Guidance Chart (doc), located on the Confluence page housing the Notice of Withdrawal of a Protocol Specification  information.

Q:  Do I need to go through the project approval process if a standard has expired and will not be reaffirmed? 

A:  No. However, when a work group has balloted a standard at STU, informative, or normative ballot, and decides the standard will be withdrawn, the Notice of Withdrawal of a Protocol Specification form on Confluence completed and must be approved by the Work Group and then submitted to and approved by the TSC.

Q:  Do I create a Jira PSS for a reaffirmation or withdrawal project?

A:  No, use the Confluence PSS template as of January 2022.  The plan is to add reaffirmation and withdrawal capability to Jira in the future.

Q:  Where can I find the Project Scope Statement Template for Reaffirmation and Withdrawal projects?

A:  Reaffirmation and Withdrawal projects will use the Confluence PSS form (https://confluence.hl7.org/display/HDH/How+to+Create+a+PSS+from+Template).  At some point in the future, these will transition to Jira.

Q:  When reaffirming a standard, does a PSS need to be created and go through the review/approval process?

A:  Yes.  Reaffirmation of a standard requires a normative ballot, hence it requires the necessary reviews and approvals. 

Balloting

Q: Do white papers need to be balloted?

A: White papers can either be balloted informative or just reviewed/approved by the Work group.  If the Work Group wants to ballot a White Paper for publication in the HL7 Standards-based Product Grid (formerly known as the Master Grid of Standards), it shall be balloted as "Informative" per the TSC, and follow the routine ballot naming convention as defined in Non-balloted Work Group level reviewed/approved white papers will not published in the HL7 Standards-based Product Grid (formerly known as the Master Grid of Standards) nor contain any type of ‘HL7 Stamp’. 









  • No labels