Skip to end of metadata
Go to start of metadata

PILOT

Entry Point for projects where no Project Proposal exists

  • Project Proposal will be required by ALL projects except:
    • projects to produce new versions of previously published standards

    • projects to complete a reaffirmation, withdrawal, or re-circulation ballot


Populate PSS

  • Project Proposal Form - will be used to pre-populate PSS
    • the fields that are verified should be summary, description, and sponsoring workgroup at minimum.
  • When WG creates PSS, identify sponsoring WG, co-sponsoring WG, USRSC (if applicable), Management Groups, and Steering Division for review
    • Should auto-populate PSS form with content from Project Proposal
  • PSS Form

Discussion - 2020-05-13

  • Need to review PSS Form as there are fields that need to be removed - complete

Sponsoring WG Approval


Consensus Review

  • See How to Review a PSS PILOT v2
  • Once the PSS is created in Confluence and JIRA issue is created, an email will be sent to co-chairs and other groups via list
    • Co-sponsors - based on co-sponsors identified on PSS
    • Steering Division - based on sponsoring WG
    • Management Group - based on artifacts selected
      • V2 MG - V2 Messages (any)
      • FMG - FHIR Extensions, FHIR IG, FHIR Profile, FHIR resources
      • CDA - V3 Documents
      • What about selection of:
        • new/modified HL7 policy/procedure/process
        • new product family
        • new product definition
        • new product project
        • creating/using a tool not listed
        • creating a new standard - who to send to
    • ARB - if external development and content is >50% developed
    • USRSC - if project indicates US Realm 
    • Zulip Announcement?
  • Specific Work Groups and governance groups may have been pre-selected by the sponsoring WG
  • Other Work Groups and interested parties can "opt in" at this stage to be involved.
  • Management Groups (V2, FHIR, CDA) - can not opt-out - options for MG:  Reviewed - no comment; Reviewed - with comment
  • Steering Division Co-chairs Review - focus on PBS metrics review for the sponsoring WG
  • ARB - 
  • Commenters must include name and WG/Group that they are commenting on behalf of
  • Commenters will be added to the watch list for this issue and will receive an email if changes are made.
  • Timeline for review - minimum of 2 weeks; maximum of 4 weeks
    • At 2 weeks point - if no comments - will send a follow-up email and remain open for 2 more weeks
    • At 4 weeks - can be escalated to the TSC if all comments have been resolved

Discussion - 2020-05-13

  • Pre-populating JIRA issue from fields in PSS
    • it is possible as long as we use dynamic PSS form (which isn't the one proposed to be used in PSS Pilot)
    • Options for notifications for Consensus Review
      • send email out to everyone - co-chairs, Mgmt Groups, ARB, US realm, etc and let them review and opt-in
      • assign groups that for review PLU send out to everyone for review who can opt in
        • either automatically capture and create sub-tasks from PSS; OR
        • manually edit form as part of PSS/JIRA issue creation
      • DECISION:  WILL SEND OUT TO EVERYONE AND AUTOMATICALLY CREATE SUB-TASKS USING CONTENT IN PSS
      • Need to create mapping of fields
    • DECISION: Notifications - will send out to WG Co-chairs and post to Zulip
    • Melva will reach out to IC co-chairs to see if notification should be sent to IC Admin list for all PSS
      • DECISION FROM IC CO-CHAIRS - YES send to IC Admin List for both PSS and Project Proposals
    • Reach out to Product Management Council
      • DECISION FROM PRODUCT MANAGEMENT COUNCIL - discussed - 2020-08-14 - agree that subtask for appropriate Management Groups should be added 
      • due date for subtaks - can this be added?
  • Will need to consider a triage step after WG Approval and before moving to Consensus Review

Discussion 2020-05-27

  • options for review - opt-out, agree, disagree
    • DECISION: Options and status will be opted-out, agree, and disagree

Reconcile Consensus Review

Modification/Edit Noted

  • all comments and issues must be resolved by the Sponsoring Work Group before it will be moved to TSC Review step.
  • if comments are not resolved at the end of Consensus Review - can give sponsoring WG 2 additional weeks to resolve comments and then move to TSC Review step
    • Curator will contact WG to determine if they need more time?
      • If so, leave open for 2 more weeks
      • If not, move to TSC Review

Discussion 2020-05-27

  • will add a triage step to move to TSC Review
  • process for re-review when comment responded to/PSS updated based on comment
    • Melva and Josh will discuss to determine how to handle
    • currently the PSS form can be updated, but there is no change to timestamp so won't notify watchers of a change and there is a "show changes" button on the PSS, but it repeats the PSS but doesn't show changes
    • could ask anyone who updates PSS to add a comment about what changed
    • may need to be a manual process

DECISION - THERE WILL NOT BE A TRIAGE STEP ADDED

TSC Approval

Modification/Edit interactions handled

  • criteria for requiring modifications and sending back to Sponsoring WG
    • the project must be clearly defined
    • it must be a project that fits into the mission of HL7
    • appropriate stakeholders must be involved

PSS Approval

PSS Rejected

  • Will need to consider a triage step after at end of Consensus Review

Discussion 2020-05-27

  • JIRA will be the source of truth for dates of review and approval
    • no need to go back to PSS to update and the dates will be removed from the PSS

DECISION - THERE WILL NOT BE A TRIAGE STEP ADDED

Future Requirements

  • have a separate set of DB tables to capture PSS content rather than JIRA
    • JIRA can be used as workflow tool
  • Link Project Proposal to PSS when we connect the 2 processes


9 Comments

  1. Looks good.  Probably should add some sort of justification or business benefit to the concept form.  

    In the Triage by TPTF step, maybe we should split into actions with reasons (we have mostly reasons in the list you provide).  Actions would be to "Approve, Reject, or Request Additional Input (modifications or explanations).  

    There would likely be a long time lag between approval by TPTF and completing a full PSS later.  Would be nice to indicate that somehow, possibly by inserting a step to line up co-sponsors and facilitators, set milestone dates, etc.  Need to discuss what happens after concept approval.   

    For last box, let's explicitly require WG approval.

  2. There needs to be differentiation between "Project approval process" and "Specification approval process".  We combine the two and that creates unneeded overhead and confusion.  If we separate the question "Should this specification exist and what should its scope be (or should the scope be revised, or should there be a new release)?" from the question of "Someone wants to work on something, do they have the right bandwidth and are the right stakeholders involved?" that would be quite helpful.  Often in the early stages of a project, it's not known what the specification outputs will be.  And in some cases, there may be numerous "projects" that lead to a single specification.

  3. I agree with Wayne about adding a Need for the project category to the initial form.

    I assume "For last box, let's explicitly require WG approval." - Wayne means the Reconcile Consensus Review /Modification / Edits - that's where I would put sponsoring WG approval step also.

    I think there needs to be clarification which of these steps is the official "PSS initiated" step, that gets the project ID assigned.

    I do like Lloyd's notion of differentiating between is this something the WG should take on and are the right people involved vs what should the outcome of that project be, though I think that can be part of the same process - we need to be sure we collect the right inomration to make both those assessments.

    I agree with Rob that there should be criteria that require re-review by TSC and adding which WG is submitting that request to the inital form is a no-brainer; I think it was just oversight. The items listed in the box under TPTF review seem to be examples of what could be on the for - nt sure that is helpful - I would rather see what criteria TPTF applies when they are reviewing the form.

    1. The key thing is that when a PSS is approved, you're not  approving the generation of a work product.  You're approving the type of work being done.  A PSS can cover multiple specifications or none and multiple PSSs can apply to the same specification.  Part of the problem with the PSS process is that we're mixing both types of approval into one - and we're not doing a great job of capturing the 'specification' bit.

  4. Agree with Wayne on getting estimated timelines up front. 

    Agree with Lloyd on differentiation between Project scope and Specification Scope.  A project may include multiple specifications - we need to discuss granularity.


    IMO ideally a Project can have 0..* Specifications.  Should we model for children of a Project?


    1. If you want to differentiate between project scope (business need) and the resulting specifications and the specifications have different timelines, are you expectign to havve the PSS for the project and then a link to one or more specification descriptions/ timelines, or how do you track the milestones regarding ballot cycle and publication, when you have more than one?

    2. A project can have 0..* specifications.  However, a specification can be a product of 1..* projects.  It may take multiple projects before a specification is brought to publication, multiple work groups may have projects that lead to the creation of a single specification.  You can also have distinct projects that result in different versions of the same specification being published over time.  There are actually 3 types of approval:

      • Approve for work (tied to 0..* specifications) to be done by a work group.  Used to manage workload as well as to communicate to the broader community, including ANSI, what we're up to
      • Approval for a new specification to be produced (used to check for overlap with other work, ensure appropriate stakeholders are engaged, scope is clearly defined)
      • Approval for a new version of a specification to be produced (check for changes in scope, ensure appropriate stakeholders are still engaged)
  5. Perhaps I'm not fully understanding. I think I agree with Lloyd about need to assure readiness to move forward with a specification. However, is this equivalent to meeting criteria for ballot submission.  I know FMG applies some stricter criteria and other (non-FHIR) specifications are left to the WGs to determine readiness.  Or are we adding another step in the process.  We do need to be cautious about looking overly restrictive but readiness is important if the standards balloted and published are to be useful.

    1. There are multiple layers here:

      1. Approval to do work.  This may contribute to 0..* existing and/or new specifications, and where multiple projects may contribute towards a single specification.  Primary concerns for 'approval' include: are we duplicating work?  Is the scope of work clear?  Are the right groups aware/involved?  Do the target groups have capacity?
      2. Approval for a specification to exist or be revised.  The specification(s) to be produced may not be identified until well into the execution of a project.  Concern include: Is the scope boundary clear and appropriate (and distinct from other existing and expected specifications)?  Is the name agreeable?  Where is the source maintained?  Is the proposed development path (who's involved) and approval path (planned ballot track) appropriate?
      3. Approval to go to ballot.  There can be numerous ballots associated with a specification - both over time, as well as in parallel (e.g. where different parts of a specification have distinct ballot pools).  We use NIBs for this purpose now.  Concerns include: Is the specification actually complete and ready for ballot?  Is it being balloted at the appropriate level?  Are other ballot pre-requisites met?
      4. Approval to publish.  This typically happens after the completion of 1..* ballots, though in theory we could publish certain things after non-ballot processes (e.g. peer reviews) if we're talking internally-binding content.  This is handled through the publication request process.  Concerns include: Is the specification actually complete and ready for publication?  Have all relevant processes for any ballots been completed?  Have other publication pre-requisites been met (e.g. WG approvals)?

      #3 and #4 have distinct approval processes.  The problem is that #1 and #2 are currently squished together.  In some cases, the relationship is 1..1 and the proposal is only made when the information for both parts are known.  However, we run into problems when the approval to do work isn't about a specification at all, is about multiple specifications or is about unknown specifications.  We're also not doing a great job of capturing all of the information needed about a specification.  Finally, it's not clear whether ANSI cares about #1, #2 or both.