Skip to end of metadata
Go to start of metadata

ARB recommendation for changes outside of ballot

IEEE has defined three terms, which are also supported by ANSI:  erratum,  amendment, corrigendum

An erratum shall be prepared when an editorial error is found in an approved IEEE standard that represents a deviation from the standard as approved by the IEEE-SA Standards Board and that could result in misinterpretation of the standard. The date of the erratum and a statement that the erratum represents an editorial correction only shall appear.

Amendments and corrigenda are processed with separate Project Authorization Request (PAR)s and balloted independently in accordance with the requirements of these procedures, including submission to the IEEE-SA Standards Board. A corrigendum may not extend the scope of the existing standard. An amendment may extend the scope of the existing standard, but if the proposed scope of the amendment PAR or the changes made in the draft amendment are found to be excessive by the IEEE-SA Standards Board, the Standards Committee shall initiate a revision PAR to replace the amendment PAR.

ARB and SGB recommend that the TSC adopt the IEEE definition for errata as follows:

Erratum:

  •  described in a document that SHALL contain only grammatical corrections to, or corrections of errors introduced during the publishing process of an existing standard.
  • SHALL be published according to the current errata publishing process as defined in the HL7 Governance and Operations Manual(GOM). (see GOM references below).
  • This is semantically the same as the Technical Correction defined in the HL7 Co-chairs Handbook.
  • From SGB: This may contain cosmetic and functional changes. Correcting errors identified as errata may be substantive in nature and do not require reballoting. Examples: A template was omitted in error, etc. The process is intended to align the document with the material originally intended to be published. 

ARB recommends that the TSC adopt the IEEE definitions for other changes as follows:

A corrigendum

  • is a document or set of documents that only corrects editorial errors, technical errors, or ambiguities in an existing  standard without extending the scope, a corrigendum  SHALL be agreed upon through the consensus process (as defined in HL7 Essential Requirements (HL7ER) as well as the GOM.)
  • Requires a project.
    • The project is the formal announcement that a change is being contemplated or applied
    • From an SGB perspective, this can contain both cosmetic and functional changes 

NOTE –A typical corrigendum may contain:

  • Corrections to equations, tables, or figures, or their associated numbering or citations in the text.
  • Corrections to technically incorrect sentences or paragraphs.

An amendment

  • is a document or set of documents that add(s) to, remove(s) from, or alter(s) material in a portion of an existing standard and MAY make editorial or technical corrections to that standard. Like the standards’ revisions themselves, an amendment SHALL be agreed upon through the consensus process ( as defined HL7ER as well as the GOM.)
  • requires a project

NOTE – An amendment to a standard MAY be prepared to maintain the state-of-the-art within the standard due to advancing technology or techniques. An amendment facilitates the timely change of an existing standard prior to its complete revision.

<END OF MOTION />

Additional Consideration Recommendation for discussion:

Up to three amendments can be approved before the standard shall be revised, unless the base standard has been approved within the past three years.

In such a case, multiple amendments may be added until the base standard is three years old. After the three-year period, (SGB/?TSC) shall defer consideration of additional amendments or corrigenda until a revision or a two-year extension request is approved

When a standard is revised, its approved amendments and corrigenda shall be removed from active status as separate documents. Existing amendments and corrigenda shall either be integrated into the base document or eliminated as indicated in the PSS or determined by the  balloting process..


References to Current definitions and content

GOM references

13.01.06 Errata A request to publish errata to an informative document shall be accompanied by a cover letter, drafted by the requesting Work Group and submitted for the approval of the Chief Technology Officer (CTO), citing the rationale supporting such a request. Refer to the CTO errata cover letter template for guidance.

13.02.06 Errata A request to publish errata to a Standard for Trial Use (STU) shall be accompanied by a cover letter, drafted by the requesting Work Group and submitted for the approval of the Chief Technology Officer (CTO), citing the rationale supporting such a request. Refer to the CTO errata cover letter template for guidance.



TSC has tasked the ARB to develop definitions of Errata and Technical Correction

Two HL7 sources have been found to date:

Technical correction and Errata (see section below copied from http://hl7tsc.org/wiki/index.php?title=Technical_Correction_and_Errata)

Interestingly enough, the TSC wiki says there are no links to this page.

There is also a page http://wiki.hl7.org/index.php?title=Errata which appears to be errata to apply CTS2.(http://wiki.hl7.org/index.php?title=CTS)


Technical Correction From the CoChairHandbook

3.7.9 A technical correction is a type of non-substantive changeA technical correction is a non-controversial change that alters a document so that it says what the WG intended to say. Technical corrections typically involve correcting changes to normative content that, during the editing process: were not made, were incorrectly made, or were inconsistently made.

When there is doubt, a WG may ask the TSC to rule whether a change is a technical correction. In this case, the TSC will ask for documentation that the WG intended to make the change and evidence that the change is non-controversial, such as:

  • A reconciliation package or meeting minutes that document the WG’s intent to make a change.
  • Meeting minutes that document a discussion of the change and record a unanimous vote to make the correction.

Here are some examples of technical corrections:

  • The CDA document refers and links to RFC 2557 "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)" If the RFC moves, the hyperlink would break. Fixing a broken hyperlink is a technical correction and a non-substantive change.
  • The RMIM Design tool never correctly named the associations to or from a role clone when that clone is a CMET. The tool was corrected. A process was run on existing material to correct the naming error. This is a technical correction and a non-substantive change.
  • In ebXML, the WG neglected to add the type attribute used in the OASIS original. The type element could be ISO OID, DUNS Number, etc. Making this change, which makes ebXML consistent with the underlying OASIS standard, is a technical correction and a non-substantive change.


Technical Correction and Errata (From TSC WIKI) 20 November 2015, at 10:50.

ISSUE

Need to make available and easy to find the definitions of Technical Corrections and Errata and how different ballot levels and different publication modalities affect options for technical corrections and errata.

Definitions

  • Errata is typically published separately as a list of changes with a cover sheet and the original standard left alone.
  • Technical correction is directly applied to the published material.



Ballot Levels

  • Normative
    • Normative documents cannot have Technical Corrections; the material as published by ANSI must remain intact
    • You can repackage it as a separate document but you cannot change the original publication. Changing the document itself requires a new ballot
    • Errata can be published for a normative standard as a list of changes that should be applied to the normative material, where the 'source of truth' is the errata sheet plus the normative standard.
    • Considerations for changes to items published in Normative Edition?

  • Informative
    • Can issue errata or technical correction
    • ANSI Technical Report corrections irrelevant as they do not receive a copy of the material nor point to our publication so resubmission of corrected material to ANSI as Technical Report update is not beneficial
    • Considerations for changes to items cited in regulation?
    • Considerations for changes to items published in Normative Edition?
    • Errata only is documented in GOM 13.01.06
      • 13.01.06 Errata

        A request to publish errata to an informative document shall be accompanied by a cover letter, drafted by the requesting Work Group and submitted for the approval of the Chief Technology Officer (CTO),citing the rationale supporting such a request. Refer to the CTO errata cover letter template for guidance.

  • DSTU
    • Can issue errata or technical correction
    • For standalone document can be an unballoted DSTU update (incremental numbering)
    • Considerations for changes to items cited in regulation?
    • Errata only is documented in GOM 13.02.06
      • 13.02.06 Errata

        A request to publish errata to a Draft Standard for Trial Use (DSTU) shall be accompanied by a cover letter, drafted by the requesting Work Group and submitted for the approval of the Chief Technology Officer (CTO), citing the rationale supporting such a request. Refer to the CTO errata cover letter template for guidance.

Publication modalities

  • FHIR (online publication)
    • overwrites current DSTU version
    • Cannot "attach" errata list and cover sheet
    • NEED Process?
  • V3
    • html-based
    • annual full publication (Normative Edition)
    • no standalone publication mechanisms for some material (e.g. CMETs)
    • Cannot "attach" errata list and cover sheet
    • NEED Process?
  • Standalone document-based or standalone PDF type publication (e.g. V2)
    • V2 has a formal definition of what is a technical correction; they are published separately. Original document errata is the source of truth.



HISTORY

Need to make available and easy to find the TSC resolution: notification of request to print errata will utilize the request to publish form and be sent to John for approval. (2013-01-12)


--BUT--


Is a technical correction (e.g. typo corrections, additions of examples or other non-substantive editorial changes) the same as an errata? Errata is typically published as a separate cover sheet and the original standard left alone. Does a technical correction imply we replace the published material? How would that be identified? How will this process differ for FHIR (online publication) versus V3 (html-based) versus any document-based or standalone PDF type publication?

Technical Correction: last resolution 2014-05-03 that Ken will ask Karen what ANSI's perspective would be on a definition of a technical correction and their acceptance. I don't recall hearing anything further since the email from February (attached).


From http://hl7tsc.org/wiki/index.php?title=2013-01-12_TSC_WGM_Agenda

  • Formalization of process for requesting publication of errata at Tracker 2403


  • Austin has discussed with John and suggests we consider a different element on the publication request. Calvin notes that some feel if the changes are significant they should be balloted. Otherwise it's just a list of addenda. They do not want to re-publish the whole thing. Republishing is considered a new version. Calvin notes if a document cited in MU at a certain version is released with errata included in a new version. If there were only 3 items a separate sheet is fine but CCDA had a huge list. Timely turnaround needs to be produced for the NIST validators. Regulators would not update their publications to accommodate a new release of the standard. Errata publications go to John and not the TSC. Full re-publication release with errata would be more useful to implementers. A publication with errata inclusion might incorporate a release number such as 2.0.1. Pat speaks to another SDO's processes (X12) that publish the original standard and also a combined guide which does not profess to be the federal standard but refers back to the standard that was balloted and approved. John notes that publishing a new release with addenda and errata combined can introduce new errors.
  • Current CCDA errata are being handled by current process. New process using publication request form indicates a committee vote but would be approved by John. MOTION: Calvin moves and Tony seconds that notification of request to print errata will utilize the request to publish form and be sent to John for approval.
  • Discussion: Normative publications go to HQ, Informative and DSTU come to TSC, and errata are approved by John. Calvin notes that errata comments on the wiki by SDWG have been moved largely to the DSTU comments site due to improvements on the web site.
  • Vote: ' unanimously approved.
    • ACTION ITEM: Lynn will update the publication request form to include errata and bring back to TSC to review.


Again on http://hl7tsc.org/wiki/index.php?title=2014-05-03_TSC_WGM_Minutes FHIR DSTU status check

  • Any outstanding questions? Woody notes that separating the reference implementations from the specification has resolved the issue. Woody moves that it's done, seconded by Paul. Need a statement of what is a DSTU and what is supporting content, in general beyond FHIR.
  • Where is the documentation of the publication of an errata or technical correction?
  • DSTU update without anyone's approval e.g. FHIR was a recent development. In V2, Tony notes, we don't change the documents in the package but an errata readme was inserted into the package.
  • Tony recalls another instance where significant changes are made between ballot reconciliation and publication by editors without reballot. The approval for edits cannot be left up to only the publishing facilitator.
  • Discussion of technical correction, typo and errata differentiation ensued.
  • Need to extract the errata publication guidance from the 2013-01-12 minutes and TSC Tracker 2403 and review and make available. Woody describes the different timeframes for these typos and technical corrections in conjunction with the Publishing WG and the contributed WGs prior to publication that should not require intervention by the CTO. Paul asks what ANSI's perspective is on technical corrections? Ken will ask Karen what ANSI's perspective would be on a definition of a technical correction and their acceptance.

Copyright © Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.