Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of contents:

Table of Contents
outlinetrue

Errata:

Definition:  Errata is the vehicle by which a technical correction is published

An HL7 errata is a package of documents that conveys the application of a technical correction to one or more published versions of a standard. 

It is formalized usingboth : 

The CTO Errata Cover Letter  is addressed to the member who downloads/accesses the standard. 

It contains

  • The date the letter was published
  • The published formal name of the standard
  • A link to the published document/standard being referenced
  • A paragraph describing the Work Group's plan plan to apply the correction to future ballots/publications
  • A list of the change(s).
  • A manifest of the file(s) included in the package which document(s) the change(s).
  • Technical Guidance and clarification notes
  • The signature of the CTO

What to do when a specification is BAP (broken as published) (formerly technical correction)

Non-substantive technical corrections to a normative published balloted specification involve correcting changes that alters a document so that it says what the Work Group intended to say. It includes edits that

  • were not made,
  • were incorrectly made
  • were inconsistently made during the editing process.

Substantive technical corrections to a normative published balloted specification require a ballot.

Changes to a STU published balloted specification can be made 

  • By technical corrections and the errata process
  • By using the STU update process, whether substantive or not.
  • By re-balloting.

Changes to informative published balloted specifications may be made 

  • By technical corrections and the errata process
  • By using the STU update process, whether substantive or not.
  • By re-balloting.

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.



The below is retained for history until the final definition is accepted.

3.7.9 Technical Corrections (existing definition from the co-chairs handbook,)

A technical correction is a type of non-substantive change.  A technical correction is a non-controversial change that alters a document so that it says what the Work Group intended to say.

Technical corrections typically involve correcting changes to normative content that were not made, were incorrectly made, or were inconsistently made during the editing process.

When there is doubt, a WG may ask the Technical Steering Committee(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.

When a technical correction is made to a standard prior to publishing, no further action is necessary.

When a technical correction is made to a document already published, the technical correction will be communicated to the Chief Technology Officer(CTO) by submitting a CTOErrata cover letter located at http://www.hl7.org/permalink/?CTOErrataLetter

Informative Document: See GOM 13.01.06 Errata

STU: See GOM 13.02.06 Errata

The below is retained for history until the final definition is accepted.

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.

Decision tree:

  • Document(s)  was/were balloted successfully and published. 

  • Document(s) was/were ballot successfully, all changes agreed upon during reconciliation applied and subsequently published.

    • You have discovered that the content contains editorial errors, technical errors or ambiguities the correction of which will NOT change the scope you should issue a corrigendum.

    • You have determined you want to add to, remove from, alter material, or change scope you have an amendment.

ARB recommends that the TSC adapt 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.

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 approvedWhen 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.

 CoChairHandbook

3.7.9 An errata/erratum is a type of non-substantive change.  An errata/erratum is a non-controversial change that alters a document so that it says what the WG intended to say. Erratum 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 An errata/erratum. 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 an errata/erratum:

  • 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 an errata/erratum 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 an errata/erratum 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 an errata/erratum 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.