|
|
| Line 3: |
Line 3: |
| | <br/><br/> | | <br/><br/> |
| | Replaced by confluence document: [https://confluence.hl7.org/display/ARB/Erratum Erratum] | | Replaced by confluence document: [https://confluence.hl7.org/display/ARB/Erratum Erratum] |
| | + | =Retained for historical purposes only= |
| | ==Definitions== | | ==Definitions== |
| | *Errata is typically published separately as a list of changes with a cover sheet and the original standard left alone. | | *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. | | *Technical correction is directly applied to the published material. |
| | <br/><br/> | | <br/><br/> |
| − | ==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?<br/><br/>
| |
| − | *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 [http://www.hl7.org/permalink/?CTOErrataLetter CTO errata cover letter template] for guidance. <br/><br/>
| |
| − | *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 [http://www.hl7.org/permalink/?CTOErrataLetter CTO errata cover letter template] for guidance.
| |
| − |
| |
| − | <br/><br/>
| |
| − | ==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.
| |
| − | <br/><br/>
| |
| − | ==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.
| |
