Page tree

12 Electronic Ballots

All HL7 ballots, be they administrative, review, or normative, shall be conducted electronically.  Electronic ballots shall provide, as appropriate:

  • The means to form a consensus group and provide necessary notifications.
  • The means to capture the vote and associated comments.
  • A method for resolving negative comments and reconciling the normative ballot.

12.01 Consideration of Recommended Actions

Prompt consideration shall be given to proposals made for developing new or revising existing HL7 protocol specifications. The TSC shall approve recommendations for all actions pertaining to approval or adoption of HL7 protocol specifications, or any portion thereof, prior to submission for ballot.

12.02 Publication Naming Convention

A naming convention has several basic objectives:

To meet these objective s, a well-constructed document name should include :  

  • The organization(s) releasing the document  
  • The family of standards relevant to the   document
  • The document   type designation  
  • A descriptive title

The   document release identifier  

HL7 defines naming rules for two types of publications specifications and ballots.  All ballots must be associated with a single target specification release , but a single specification release may be vetted by multiple ballots, whether part of the same ballot cycle or separate cycles.  Ballot names will always identify the specification they are associated with.  Ballots will also strive to ensure consistency of naming across artifacts related to the same product families.

12.02.01 Constructing HL7 Ballot and Protocol Specification Names

Notes to TSC: Major changes for specification names:

  1. Broke this section out from ballot names to make explicit what the expectations were for each type of name
  2. All family names are always expressed via their abbreviations for consistency as well as conciseness.  (Lots of implementers don’t know or care what FHIR or CDA stand for.)
  3. Ensured that “Cross-Paradigm” never appears in a product name
  4. Versions of product families a re expressed as releases (abbreviated ‘R’), while versions of derived/child specifications within product families are expressed as Editions.  This helps reduce confusion when versions of both the family and derived product are relevant
  5. Tightened expectations to remove unnecessary optionality
  6. Drop the PI ID [LC7] from names – Names need to be as friendly as possible to outsiders and PI ID is very much an HL7-insider thing.  It can be exposed as metadata in the ballot announcements and in the NIBs - which are easy enough for insiders to find
  7. Reaffirmation is treated as a type of ballot.  (Saying Normative Reaffirmation is redundant)

The full document name shall begin with an organizational identifier followed by family name, product type and release number with a subfamily name, product type and release number, if applicable, then the product name and release number followed by the realm designation, if applicable, and the ballot type and number.  In the case of a reaffirmation ballot the term “Reaffirmation of” shall precede the organization identifier.

 

There are three vari ations on naming convention for protocol specifications, all described below.  The first is for naming releases of a product family.  The second is for naming products derived from a product family.  The final syntax is for artifacts that are not part of a product family or that span product families.

The naming construct is described below using a notation of {required} or [optional] with literals expressed in bold italics .

STRUCTURE

Comments

[ Reaffirmation of ]

 

{Organization Identifier}

 

< {

One or more of the following three 3 line items required

{ [ Family Name } ] [Product Type] [ R elease   { [ Release Number } ]] :

{ [ Sub-f F amily Name } ] [Product Type] [ R elease   { [ Release Number } ] ] { Product Type } : {Product Name} , Edition   {Edition Number}

[Product Type :   ] { [ Product Name ] } [ R elease   { [ Release Number } ]]

> }

 

[Realm Designation]

See HL7 Version 3 Standard > Vocabulary > HL7 Value Sets > HL7 Realm

The following elements are specific to ballot names and shall not appear in final document name s .

[Designation] [Ballot Type] Ballot

Designation shall be 1st, 2nd, etc.

PI ID {Project Insight ID number}

Ballot metadata; ID number shall have hyperlink to Project Insight

12.02.01.01 Organization Identifier

The Organization Identifier shall be:

  • HL7 indicating a Health Level Seven International document
  • HL7/ [ Other ]” where [Other] is the abbreviation/short name for the other organization   [ such as NCPDP ] , indicating an HL7 document published in conjunction with another organization

12.02.01.02 Family Name

The standard family names are Version 2.x ( V2.x ) ; Version 3 ( V3 ) [note: V3 itself does not have a release number, although each of its products typically will] ; Clinical Document Architecture ® ( CDA® ) [note: CDA shall be further designated as R1 or R2 ] ; Electronic Health Records System-Functional Model ( EHRS-FM ) ; Fast Healthcare Interoperability Resource ( FHIR® ) ; or [LC8] DAM .  W w here a document specification is based on includes reference to two or more family names it may be identified as a Cross Paradigm Specification , the Family Name naming option cannot be used and a stand-alone title will be used instead . Note: Specifications from the Cross Paradigm family will not be noted as such.

In the case of a Standard or Standard for Trial Use (STU) the full family name shall be used; e.g., Fast Healthcare Interoperability Resource or Clinical Document Architecture®.  In lieu of t T he full family name the appropriate acronym shall may be used for all specification names, including the name of the base specification.  [LC9] Specifications shall document the full name as part of the specification text Implementation Guides, Profiles, and other documentation .

Subfamily names are specific to a given family and are not further defined in this document. 

12.02.01.03 Release Number [LC10]

The Release Number is a unique identifier for a particular product family or stand-alone primary specification.  It is generally expressed as a version number with the syntax {maj or}.{minor} – e.g. 3.2.  It reflects the number of the final publication of the artifact intended f or use by implementers.  It remains the same across all ballots until the specification is published.   The major number can be used alone if there is no minor release.   The release number is not reset when a product transitions from STU to normative or at any point.  The TSC may approve alternate release number syntaxes – for example they year-based identifiers used for HL7 v3 publications .  The release number must be specified when naming derived specifications unless the s pecification applies to multiple releases of the base product family in which case it must be omitted.

12.02.01.0 4 3 Product Type

Product types are defined as Specification or Standard; Domain Analysis Model [LC11]   (DAM) [LM12] ; Service Functional Model (SFM) ; Functional Model (FM) ; Functional Profile (FP) ; Implementation Guide (IG) ; Logical Model [note: a Logical Model is not a Cross Paradigm Specification] [LM13] ; Profile, White Paper, and Guidance [for documents such as a Cookbook or Companion Guide].  The TSC may, at their discretion, declare additional product types.

12.02.01.0 5 4 Product Name

The Product Name is specified by the Work Group when they initiate a PSS to create a new or update an existing Protocol Specification; however, the Product Name may be revised upon submission of the Notice of Intent to Ballot ( NIB ) .   If a product is based on higher-level derived artifacts (e.g. an implementation guide based on another implementation guide, a services functional model based on a higher - level model , the product name may include references to one or more of those higher - level artifacts , including the versions of them.  This should only be done if it is a necessary part of the descriptive name to ensure uniqueness or to ensure implementers understand what the artifact is.  Detailed metadata should be provided in the artifact itself.  All efforts should be made to keep the product name concise and easy to use. [LC14]

12.02.01.0 6   Edition Number

The Edition Number is a unique number for the Product Name within the scope of the product family.  The term “Edition” is used to avoid confusion with the “Release” of the product family on which the Edition is based .   The term Edition is used for all artifacts derived from a based product family p ublication – even if there is a hierarchy of artifacts.  For example Edition 1 of implementation guide B, might depend on Edition 3.1 of implementation guide A , which in turn depends on R4 of the product family specification.   Edition Numbers follow the same format as the Release Number with respect to major and minor version numbers .

 

The Edition Number does not reset when a derived publication advances to a newer release of the same product fam ily.  Multiple publications with different release numbers for the base specification and the same edition number and product name are possible if multiple publications are produced with essentially the same content for different releases of the underlying product family.

12. 02 . 01. 05 Ballot Level

The Ballot Level defines the type of Review Ballot being undertaken: Informative; STU [note: STU numbering is independent of the normative release level the product may ultimately be assigned] ; or Comment -only [note: a Comment-only ballot is not typically numbered given that it is issued for a specific reason, such as reaffirmation, or as a precursor to an Informative or STU ballot] .

The TSC has issued specific guidance as to sub-numbering the release number for a STU update.  Please refer to TSC Policy and Guidance to Work Groups on STU Updates vs. STU Ballots .

12.02.01.0 7 6 Examples

HL7 FHIRPath R1

HL7 FHIR® R4

HL7 V3 R2019

HL7 CDA® R2.1

[NOTE: hyperlinks illustrated but not included]

HL7 CDA® R2 Implementation Guide: Patient-friendly language for Consent Directives, Release Edition 1   (1 st Informative Ballot) PI ID 1130

HL7 EHR-System Usability Conformance Criteria , R elease 1 (Comment-only Ballot) PI ID 995

HL7 FHIR® R2 Profile Implementation Guide [LM15] : Data Access Framework (DAF), Release Edition 1 (1 st STU Ballot) PI ID 1143 - US Realm

HL7 Business Architecture Model (BAM) , R elease 1 (1 st Informative Ballot) PI ID 915

HL7 Service Functional Model: Care Coordination Service (CCS) , R elease 1 (1st STU Ballot) PI ID 924

HL7 V ersion 3 Standard: Biomedical Research Integrated Domain, Release Edition 2 (1 st STU Ballot) PI ID 1120

HL7 V 2 .x ersion R 2.7.1 Implementation Guide: Message Transformations with OASIS Tracking of Emergency Patients (TEP), Release Edition 1 (2 nd Informative Ballot) PI ID 970

Reaffirmation of HL7 V ersion 3 Standard: Pharmacovigilance - Individual Case Safety Report, Part 1: The Framework for Adverse Event Reporting, R Edition 2 (1st Normative Ballot) PI ID 1258

 

All examples shown above reflect ballot names; the ballot designation and Project Insight ID shall not appear in the document name used for publication.

12.02.0 2 1 Constructing HL7 Ballot and Protocol Specification Names

Notes to TSC: Major changes for ballot names:

  1. Broke this section out from specification names to make explicit what the expectations were for each type of name
  2. Include the date as the primary distinguishing feature for a vote and remove counts of “what ballot occurrence” it is.  I.e. Will no longer expose “2 nd STU ballot.  Instead, we’ll just show 2018-05 ballot – which is how everyone tracks this information and it’s also how the ballot desktop supports locating a ballot.  Date appears at the beginning to be consistent with how it will appear (and MUST appear) in Jira [LC16] .
  3. Drop the PI ID from [LC17] names – Names need to be as friendly as possible to outsiders and PI ID is very much an HL7-insider thing.  It can be exposed as metadata in the ballot announcements and in the NIBs - which are easy enough for insiders to find
  1. Reaffirmation is treated as a type of ballot.  (Saying Normative Reaffirmation is redundant)
  2.  

The full document name shall begin with an organizational identifier followed by family name, product type and release number with a subfamily name, product type and release number, if applicable, then the product name and release number followed by the realm designation, if applicable, and the ballot type and number.  In the case of a reaffirmation ballot the term “Reaffirmation of” shall precede the organization identifier.

The naming construct is described below using a notation of {required} or [optional] with literals expressed in bold italics .

STRUCTURE

Comments

{ Ballot Cycle }

 

{ Specification Name} :

[ -   Qualifier ]

: {Ballot Level}

[ Recirculation ]

 

b allot

 

The following elements are specific to ballot names and shall not appear in final document name s .

[Designation] [Ballot Type] Ballot

Designation shall be 1st, 2nd, etc.

PI ID {Project Insight ID number}

Ballot metadata; ID number shall have hyperlink to Project Insight

12.02.0 2 .0 1   Ballot Cycle [LC18]

The “opening” month of the ballot’s ballot cycle expressed in YYYY-mmm format .  Note that the ballot cycle date remains the same even for ballots that have delayed opening to a subsequent month.

12.02.0 2 .0 2   Specification Name

The expected name for the specification that will result from the balloting process, as defined in section 12.02.01.   This will include expected release numbers, edition numbers, etc.  It will remain the same for all ballots targeting the same specification publication

12.02.02.03 Qualifier

A few words that describe the subset of the content in the target publication being reviewed by the ballot.  Qualifiers should only appear for ballots that are limited to not include the full scope of the target publication.   Note that the published specification will only include the Specification Name and not the qualifier.  Information about the approval status of the limited subset will be conveyed in metadata of the resulting published specification

12.02.0 2 1 .0 4 5 Ballot Level [LC19]

The Ballot Level defines the type of Review Ballot being undertaken: Informative; STU [note: STU numbering is independent of the normative release level the product may ultimately be assigned] ; or Comment -only [note: a Comment-only ballot is not typically numbered given that it is issued for a specific reason, such as reaffirmation, or as a precursor to an Informative or STU ballot] . [LM20]

The TSC has issued specific guidance as to sub-numbering the release number for a STU update.  Please refer to TSC Policy and Guidance to Work Groups on STU Updates vs. STU Ballots . [LM21]

12.02.02.05 Recirculation

The string “Recirculation” is included as a qualifier of the ballot name if a specific ballot is being subjected to a recirculation vote.  Note that the ballot cy cle listed is for the original ballot as that’s the ballot being recirculated and whose pool applies. [LM22]

[LM23] 12.0 2.01.06 Examples

2018-May HL7 FHIRPath R1: Comment ballot

2018-May HL7 FHIR® R4 – Patient: Normative ballot

2018-May HL7 CDA® R2.1: Normative Recirculation ballot

[NOTE: hyperlinks illustrated but not included]

2018- May   HL7 CDA® R2 Implementation Guide: Patient-friendly language for Consent Directives, Release Edition 1 : (1 st   Informative b B allot ) PI ID 1130

2018- May   HL7 EHR-System Usability Conformance Criteria , R elease 1 : ( Comment -only b B allot ) PI ID 995

2018- May   HL7 FHIR® R 2 Profile Implementation Guide : Data Access Framework (DAF), Release Edition 1 : (1 st   STU b B allot ) PI ID 1143

2018- May   HL7 Business Architecture Model (BAM) , R elease 1 : (1 st   Informative b B allot ) PI ID 915

2018- May   HL7 Service Functional Model: Care Coordination Service (CCS), R elease 1 : (1st STU b B allot ) PI ID 924

2018- May   HL7 V ersion 3 Standard: Biomedical Research Integrated Domain, Release Edition 2 : (1 st   STU b B allot ) PI ID 1120

2018- May   HL7 Version V2 .x R 2.7.1 Implementation Guide: Message Transformations with OASIS Tracking of Emergency Patients (TEP), Release Edition 1 : (2 nd   Informative b B allot ) PI ID 970

2018- May   Reaffirmation of HL7 V ersion 3 Standard: Pharmacovigilance - Individual Case Safety Report, Part 1: The Framework for Adverse Event Reporting, Edition R 2 : (1st Normative Reaffirmation b B allot ) PI ID 1258

All examples shown above reflect ballot names; t T he ballot date and ballot level will not appear in the ballot desktop in views where that information is explicit in other parts of the screen designation and Project Insight ID shall not appear in the document name used for publication.

12.02.02 Approving HL7 Ballot and Protocol Specification Names

Informative Documents and STU:
Ballot and protocol specification names shall be approved by the TSC.  In the case of ballots during the Notice of Intent to Ballot ( NIB ) process.  [LC24] In the case of protocol specifications during the review and approval process of the Publication Request Template .

Other Documents:
The Work Group proposing a new document title or a change to an existing document title, for other documents published as official HL7 documents (carrying an HL7 copyright and logo) shall obtain approval from the TSC as early as possible; preferably before the document is circulated widely for review, but certainly prior to publication.

Documents in Progress
The TSC may require a change to the title of documents already in progress, in ballot, or in technical editing after ballot for conformance with an established convention.


[LM1] To be useful, names must be concise.  Otherwise they don’t get used as names.  Names cannot be fully descriptive.

[LM2] A product name cannot and should not do that.  Specifications may well contain a mixture of ANSI-approved and non-ANSI-approved content.  The approval level of a specification (or a piece of a specification) is metadata, not part of the name.

[LM3] Our primary target audience is the implementer community, not HL7 insiders

[LC4] ou target audience includes implementers, but also all other users of our  specificatiions - business, clinical, operations, etc

[LM5] Publications aren’t necessarily documents

[LM6] Names are of limited value in determining relevance.  They can, at best, provide a high-level filter of “potentially relevant”

[LC7] This was never part of the name, just inromation in the ballot announcement

[LC8] Would rather see Conceptual Model ere, not DAAM

[LC9] I think the base specification should spell out the name

[LC10] How does this relate to how we do dot releases for unballoted STU updates?

[LC11] Would like to see this replaced by Conceptual Model

[LM12] We don’t show or use abbreviations for product types because these are not key brands and will not be widely understood by implementers.

[LM13] This did not seem like an appropriate place to make such a statement.  If it needs to be said, it should be in a section that specifically discusses the Cross paradigm family

[LC14] I thin k the references to other higher level artifacts should be part of the metadate, not the name

[LM15] In FHIR, individual profiles are never subject to ballot

[LC16] Not sure I agree – for balloting, whether it is the first or second ballot at a given level is pertinent

[LC17] See comment above

[LC18] What about out of cycle ballots, in addtion to de;ayed opening?

[LC19] Earlier, you proposed Reaffirmation as another ballot type. We are also considering withdrawal ballots in some cases

[LM20] In HL7 Essential Requirements, this will be changed to only reflect Normative and Reaffirmation levels as those are the only types of relevant there.

[LM21] The TSC may wish to revise this guidance to reflect general guidance on release and edition numbers – independent of whether an update is being made to a specification regardless of whether it is informative, STU, Normative or mixed.

[LM22] This section will only appear in the HL7 Essential Requirements, but listing it here for a complete view

[LM23] The TSC may wish to revise this guidance to reflect general guidance on release and edition numbers – independent of whether an update is being made to a specification regardless of whether it is informative, STU, Normative or mixed.

[LC24] Sentence fragment