Page tree
Skip to end of metadata
Go to start of metadata

Approved by the TSC 2022-04-11

According to the HL7 GOM, after a STU has passed ballot and published, it may be updated without recourse to additional balloting.

GOM Section 14.02.06 Results of the Trial Use Period

Where the evaluation and comment period results in a need for substantive changes to the STU, the resulting content for normative ballot may embody such changes or a revised STU may be released for further evaluation without recourse to a review ballot. In either case, should there be a need for substantive changes, the normative ballot content or the subsequent revised STU is not bound to maintain compatibility with the initial STU. Under such circumstances, given that the intent of an STU is to improve the viability of the subsequent normative HL7 Protocol Specification (§02.02), it is the obligation of the responsible Work Group to select enhancement over compatibility with the initial STU.

Despite this GOM provision for releasing a revised version of a STU without recourse to ballot, many STU’s are taken back to subsequent ballots. In part, this may be due to a misunderstanding that any change to a STU requires additional balloting. The above GOM provision makes it clear that there is no such requirement. The purpose of this policy is to provide work groups with guidance on when it is appropriate to revise a STU via an unballoted STU update vs. an additional balloted revision of the STU.

TSC Policy

There are 3 paths for updates to STU specifications

  • STU Update
  • STU Ballot
  • Technical correction/errata

STU Updates

STU Updates allows changes to a STU that are unballoted

  • Minor updates can include incorporation of STU comments, errata, additional implementation guidance and minor tweeks
  • Can include larger changes such as technical changes within the scope of the original solution as long as:
    1. Work Group and co-sponsoring Work Groups are consulted and agree to the scope changes
    2. Stakeholders, including HL7 Members and Community, associated with the original STU agree to the STU Update process
  • Major changes such as additional of major new functionality or changing exchange paradigm should consider an additional ballot instead of an STU Update
  • Work on a STU Update SHALL be associated with an approved HL7 project.
    1. This may be same project as the original project the STU was balloted under as long as the project covers the scope of the changes being included in the STU Update. The existing project scope may need to be revised to cover the new scope introduced by the STU Update.
    2. All work groups that are sponsor or co-sponsor to the project must agree to the scope of the STU update.
  • The release identifier for a STU Update will be an incremental (i.e., “dot”) release
    1. Example: the first STU Update for a previously balloted STU (“R1”) would be identified as “R1.1”
  • The updated version of the specification must be frozen and available for review – the format/access of the updated version will be dependent on the product family.
  • The Jira Specification Feedback Project must be updated to include the artifacts and version for the STU Update so that comments can be captured in Jira
  • Once the work group(s) has completed making the changes to the STU for the STU Update, the revised version of the STU should be vetted by one of the following processes:
    1. Comments captured in JIRA during a peer review process
    2. Comment Only ballot
  • The STU Update process must be announced broadly including the Sponsoring and Co-Sponsoring Work Group List Serves, Co-Chair List Serve and via the appropriate Zulip Streams
  • Once the WG vets the updated STU and has voted to approve the new publication package for the STU update, a Publication Request form SHALL be submitted to the TSC along with the new publication package requesting publication of the STU Update
    1. As part of the publication request the work group(s) SHALL document the type of review process used to validate the changes made to the STU as part of the STU Update.
    2. As part of the publication request, the work group(s) may request an extension of the STU period. If an extension is being requested, a rationale for the extension SHALL be provided
  • STU Updates do not change the expiry date of the original STU Publication. If the STU needs to be extended, an STU extension request must be submitted to the TSC

STU Additional Ballots

STU Additional Ballots are revisions to an existing STU that will go through the STU ballot process.

  • Work on a STU additional ballot SHALL be associated with an approved HL7 project.
    1. This may be same project as the original project the STU was balloted under as long as the project covers the scope of the changes being included in the STU additional ballot. The existing project scope my need to be revised to cover the new scope introduced by the STU additional ballot.
    2. All work groups that are sponsor or co-sponsor to the project must agree to the scope of the STU additional ballot.
  • The release identifier for a STU additional ballot will be a full release
    1. Example: the first STU additional ballot for a previously balloted STU (“R1”) would be identified as “R2”
  • The work group(s) will prepare the changes to the STU and ballot them according to the normal HL7 process for STU ballots including reconciliation, reballot, publication preparation and publication request.
    1. The new full release of the STU is considered separate from the prior release in regards to the trial use period.

Technical Corrections

Technical Corrections are revisions to a specification to fix issues where edits were not made, were made incorrectly, or made inconsistently.  Technical corrections

  • Cannot be enhancements or new use cases or a change in the scope of the specification
  • Published as an Errata
  • Once the WG vets the corrected STU and has voted to approve the new publication package for the technical correction, a request is sent to the Product Management Group for approval
  • Once approved by the Product Management Group, a Publication Request form SHALL be submitted to the TSC by the Work Group(s) along with the CTO Errata Cover Letter which includes:
    1. The date the letter was published
    2. The published formal name of the standard
    3. A link to the published document/standard being referenced
    4. A paragraph describing the Work Group’s plan to apply the correct to future ballot/publications
    5. A list of the change(s)
    6. A manifest of the file(s) included in the package which document(s) the change(s)
    7. Technical guidance and clarification notes
    8. The signature of the CTO

TSC Guidance Matrix

The following table provides guidance on when a STU update. 

When deciding whether to handle a set of changes as a STU update vs. additional balloting, the work groups(s) should consider the level of uptake of the STU by HL7 members. Note it is principally HL7 members who participate in ballots. Non-members can pay to join ballot pools, but that option is rarely exercised. Uptake by non-members can also be considered a factor, but those non-members do not typically participate in HL7 balloting.

 

Minor changes*

Large changes**

Major scope changes***

No STU uptake by HL7 Members and community

STU update via peer review process

STU update via peer review process

STU Additional Ballot

Limited STU uptake by HL7 Members and community

STU update via peer review process

Either STU Update via peer review process or STU Additional Ballot

STU Additional Ballot

Moderate STU uptake by HL7 Members and community

STU update via peer review process

Either STU Update via peer review process or STU Additional Ballot

STU Additional Ballot

Major STU uptake by HL7 Members and community

STU update via peer review process

STU Additional Ballot

STU Additional Ballot

 

* Minor Changes include incorporation of STU comments, errata, additional implementation guidance, minor tweaks such as addition/removal/changes to fields/data elements, clarifications, etc. Co-sponsoring work groups should be consulted and agree to the scope of these changes

** Work groups may choose to include larger changes within the scope of a STU update.

  • Co-sponsoring work groups should be consulted and agree to the scope of these changes
  • Stakeholders associated with the original STU should agree to using the STU update process
  • Significant technical changes within the scope of the original solution are one example of large changes

***Work groups considering major changes in scope or approach to a STU should consider the STU additional ballot approach instead of the STU update approach.

  • This includes addition of major new functionality
  • Changing the underlying exchange paradigm (i.e., switching from messaging to documents)

Co-sponsoring work groups must be consulted and agree to the scope of these changes

  • No labels