Develop definition of Errata,Technical Correction

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

SEE also : SGB Notes on ARB definition of Errata,Technical Correction

 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.