Page tree
Skip to end of metadata
Go to start of metadata

Last Revision Date: 04 February 2022

Past versions of the co-chair handbook have been archived and are available upon request.



Chapter 1 Introduction to the Co-Chair Handbook


FOREWORD

There are numerous responsibilities that you assume as co-chair of an HL7 Work Group (WG) or Board appointed committee.  The content of the following pages is provided to assist you with those responsibilities. The HL7 Essentials Confluence Space provides quick references to key information.

In addition to this guide, all co-chairs should be familiar with:

    • The HL7 Bylaws – which are updated as needed
    • The HL7 Governance and Operations Manual (GOM) – which may be updated three times a year
        • Special Note on Bylaws and GOM: Currently these are PDF documents on HL7.org. References to these documents will not take you to the section defined in these documents. The hyperlink will take you to the document, then scroll down to the table of contents and hit CNTRL then left click the mouse on the section and it will open that document in another page in HTML directly at the reference.
    • The HL7 Essential Requirements: Due Process Requirements for HL7 American National Standards (HL7 ER) – which may be updated three times a year

Throughout this guide, there are links to other documents and material, as an example in the above section, clicking on Bylaws will take you to the Bylaw document. For documents like the Bylaws or the GOM, the link will take you to that document, there will be a reference to the specific area in the document, moving down to the table of contents, then holding the CNTRL key and left clicking on the page number will take you directly to that section of the document.

If you have suggestions for improvements/corrections to the Co-Chair Handbook use the “Submit changes to this page”  at the top of this space to add an issue in Jira for the proposed change.

Overview

This guide has the following Chapters:

    • Introduction -  Chapter 1 provides an overview of the Handbook
    • Your Role as Co-Chair - Chapter 2 provides information to help you as you get started as a new co-chair
    • Work Group Planning - Chapter 3 provides guidelines on Work Group (WG) planning and WG Co-chair responsibilities.
    • Project Management - Chapter 4 provides information about project planning and updating project plans.
    • Balloting – many new co-chairs have questions about balloting.  Chapter 5 provides guidance for the ballot process for both normative and review documents.  
    • Working Group Meeting Planning - Chapter 6 has information about preparing agendas, hosting meetings for other WGs, scheduling room space and other critical information about the Working Group Meeting (WGM).
    • WG Health - Chapter 7 reviews the WG Health requirements including making sure to include updates to WG projects during the WGM.

Available resources:

    • Robert’s Rules of Order – provides an overview of and tips for conducting meetings using the official Robert’s Rules of Order can be found at: Robert's Rules
    • Decision Making Practices (DMP) – provides guidance for conducting the business of the WG you are co-chairing.  This section covers areas such as what constitutes a quorum, how to make decision on conference calls, etc. The default DMP can be found at: Default DMP
    • HL7 Tools and Resources  - Various tools and resources are available for people creating and implementing HL7 standards. The tools and resources that we are aware of are organized below by standards and/or function and can be found at: Tools and Resources
    • HL7 Standards - A framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information and can be found at: Introduction to Standards.
    • Confluence - Confluence is a collaboration space and used to house minutes, documents and other work items for the work groups and projects. Each work group, HL7 FHIR Accelerator and governance group has a space on HL7's Confluence site. Confluence also houses the HL7 Essentials, which provides instructions and processes for participation in HL7, and many of the forms and items that are used by co-chairs and others actively involved in the development of standards.
    • JIRA - JIRA is the tool currently used to record issues related to all HL7 specifications and track Work Group tasks.
    • Github - the version control system used to support the development of HL7 specifications and artifacts.  It can be found at https://github.com/HL7.  If your WG needs a Github Repository for the development of a specification, see: Request Github Repository
    • chat.fhir.org - also known as Zulip, is an open-source chat. Communications on Zulip are organized by streams, and users choose the streams they wish to subscribe to. The HL7 community communicates on many, many topics using Zulip and streams are organized in such a way that catching up on any particular conversation is easy. It is the go-to place to ask and receive answers to your pressing HL7 questions.


HL7 International Organization

A brief overview of the HL7 Organizational Structure 

HL7 International Org Chart on the Website: http://www.hl7.org/documentcenter/public/calendarofevents/2022HL7OrgChart.pdf

Overview of the Technical Steering Committee (TSC)

Understanding the structure of HL7 and key players will be helpful in your role as an HL7 Work Group (WG) Co-chair.   Section 10 of the GOM established the TSC to "facilitate the coordination and activities of the Working Group".  The TSC is responsible for product project approval and management oversight including: 

  • Establishing and maintaining an HL7 Architecture, development methodologies, and work processes to be used by The Working Group in developing HL7 Protocol Specifications.
  • Establishing the precepts (rules) that management and methodology groups apply as operational instructions across domains within the scope of the Technical Steering Committee (TSC).
  • Ensuring that the efforts of The Working Group to produce protocol specifications proceed at a reasonable pace.
  • Ensuring that The Working Group collaborates smoothly and covers the scope of work in a consistent manner.
  • Managing the ballot and distribution process for those HL7 Protocol Specifications identified by the Executive Committee as intended to be freely available to the public.

The composition of the TSC is as follows:



Helpful information:



Chapter 2 Your role as Co-chair

Summary of Responsibilities

This section outlines many of the key requirements and responsibilities you have taken on as co-chair.  At its core, the co-chair role entails providing the leadership, the stewardship, and the oversight of the workgroup in which you are serving, to help that community achieve its mission.  In so doing, there are several competing priorities for which you and your fellow co-chairs are responsible, including:

  • Managing the overall group consistent with the policies documented by the HL7 organization in general, and the Governance and Operations Manual and the HL7 Essential Requirements in particular
  • Maintaining the integrity and trust of the community, assuring that contributors are able to effectively participate, that all voices are being heard, and that decisions are being made consistent with the decision-making practices that govern the workgroup
  • Providing thought leadership to help divergent participants, organizations, and perspectives come together, seeking a consensus whenever possible, on effective work products that advance your mission consistent with your workgroup charter
  • Supporting administrative activities to support the needs of the HL7 organization, community, and external stakeholders

Co-Chair Election and Term

Co-chairs are elected for a two-year terms and may be re-elected without limit as defined in the GOM (§ 11.03.02 Work Group Co-chairs) . When a new WG is formed, half the co-chairs will be elected to one-year terms and half the co-chairs will be elected to two-year terms.  This ensures that the elections from that point on will be staggered so that there is continuity of leadership.

Prior to the end of your term HL7 staff will notify you that your term is ending.  The HL7 process for electing co-chairs (GOM §08.02 Annual Nomination and Election of HL7 Leadership by Administrative Ballot and GOM §08.02.07 Work Group Co-Chairs) involves a 45-day nomination period that is announced to the membership.  Anyone who is a current individual member or representative of a current organizational or Affiliate member subscribed to the WG's primary list serve one week prior to the start of the nomination period can be nominated or can nominate themselves.  HL7 Headquarters will contact all nominees to ensure that they wish to serve if elected.  Each nominee will be asked to draft and submit a brief position statement and provide affirmation from at least one existing co-chair (not themselves) and one other Work Group member that they are an active member of the Work Group in question and have the capacity to fulfill the co-chair duties.  Position statements are published to the membership at large, along with an announcement of the elections.

WG Co-Chair elections are held on an annual schedule matching the current schedule for the Board and Technical Steering Committee elections.  The process follows this schedule:

  • Nominations open May 1 and continue through June 15;
  • The election period is July 1 through July 31
  • Runoffs, if necessary, are held from August 7 through August 21
  • The results are announced during the Plenary Session/September WGM
  • Elected individuals are seated January 1 of the following year

Should you or one of the other co-chairs need to resign before your two-year commitment expires, notify HL7 Headquarters bemail.  HQ will attempt to seek nominees and include the open co-chair position in the next regularly scheduled election.  Your WG may appoint an interim co-chair (GOM §11.03 Work Group Co-chairs) to serve until the next scheduled election.  The interim co-chair may be a nominee in the subsequent election.  HQ will then formally announce the open co-chair position as part of the normal process and elections will be held according to the schedule above.

GOM §08.02.07 defines the criteria that must be met to be eligible to be nominated as a Work Group co-chair:

  • must be current individual members; individuals who represent a current Organizational member although not necessarily as a designated voting representative; or individuals who represent a current Affiliate member although not necessarily as a designated voting representative.
  • must have affirmation that they are an active member of the WG in question and have the capacity to fulfill the co-chair duties as required from at least one existing co-chair of the WG in question (not themselves) and at least one member of the WG in question (not themselves).

Co-Chair Training

Training is provided to WG co-chairs.  Here is also a link to the most recent Power Point presentation used at the January 2021 WGM for training new WG co-chairs .

Key Documents for this chapter

Co-Chair Training

Conference Call Center

GOM (§08.02 Annual Nomination and Election of HL7 Leadership, §08.02.07 Work Group Co-chairs, §08.04 Representing HL7,  §11.03 Work Group Co-chairs)

List Servers

New Work Group Formation Template

Relationships with Organizations Outside HL7

Roberts Rules of Order

Work Group Meetings

Work Group Health Components

World Clock



Who can speak on behalf of HL7

Co-chairs cannot speak on behalf of HL7 except where allowed by the policy, as provided in GOM §08.04 Representing HL7.

Subscribing to and participating on HL7 Lists

You must read emails sent from the HL7 Co-chairs List.  HL7 Headquarters will subscribe you to this list when it learns of your election to a co-chair position. The list is cochairs@lists.hl7.org

You must sign up for and participate in any list servers involving or dedicated to your WG including list servers for projects for which your WG is responsible. complete list of list servers is available.

Most co-chairs should also sign up for the Modeling and Methodology (MnM) list.

New Co-Chair Updates

HL7 HQ will update the page dedicated to your WG on the HL7 web site to reflect your status as co-chair.  HQ staff will not update individual WG Confluence pages. Confluence page edits are the responsibility of the WG co-chairs.

New Co-Chair of a New Work Group

When the TSC approves a new WG, the TSC Program Manager (TSCPM) distributes a task list to HL7 HQ staff to initiate the creation of all the associated web services that will be needed. Review the task to make sure the most current version of your mission/charter statement guidelines and your "New Work Group Formation Template" have been attached to the task.  Until both of these documents are available by being attached to the task, the webmaster will not be able to complete the task of making a web presence for your WG.  Please allow the webmaster at least 5 business days to complete this task. 

A new list server will be created for your WG. The new WG list server will typically be announced via an electronic update from Headquarters that is sent to all members.

Use of Confluence

As co-chair of an HL7 WG, you are responsible for posting meeting minutes and documents related to all meetings/business of the WG that you chair.  The content on Confluence is key to having HL7 members understand what your WG is working on so it is important that the content is kept up to date.  Any changes to your Mission and Charter and DMP must be updated on the HL7 Website in addition to Confluence and must be approved by the TSC before the changes are published in either place.

A Confluence Space has been set up for each WG and all WGs use Confluence for their agenda, minutes and documents. You can work with webmaster@hl7.org  if you need help using Confluence.

Confluence templates are available for Teleconference agenda and minutes as well as WGM agendas and minutes.

To create a new agenda or minutes, go to your WG Confluence space and click on the 3 "dots" to the right of "Create" in the blue bar.

You can select the type of page you want to create:

  • Teleconference Agenda/Meeting Notes
  • WGM Agenda
  • WGM Minutes
  • WGM Attendance Log

Ensure that Meeting Minutes are Taken

If you have a WG secretary or a co-chair who is responsible for taking minutes, verify that he or she will be in attendance.  Otherwise, ask for a volunteer to provide notes or minutes in electronic form so you can focus on chairing the meeting. 

Minutes can vary widely in their depth of coverage.  WGs must use Confluence for recording their minutes.  There is an agenda/meeting notes templates available for use. 

To create a teleconference agenda/meeting notes page in Confluence, go to the page you want to create the agenda or meeting notes under.  Click the "three dots" beside the "Create" button on the blue bar. 

Click "Show More" and scroll to find the "Teleconference Agenda/Meeting Notes" Template. 


The minutes should include:

  1. A list of attendees
  2. Antitrust Statement:The following must appear in the agenda/minutes, but is not required to be read out. "Professional Associations that bring together competing entities, such as HL7, are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 activities, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust policy as stated in §05.01 of the Governance and Operations Manual (GOM)."
  3. Precisely worded motions that were made along with indication of how successful they were (passed unanimously, passed without objection, or the actual number of votes for, against, and abstentions).  Motions and tallies related to ballot reconciliation can, instead, be recorded in the reconciliation spreadsheet, and posted as noted under item 5 below.
  4. Descriptions of any associated work products (white papers, draft documents, presentations, etc.).
  5. The agenda for the next meeting
  6. Electronic copies of all work products of the WG including papers that were presented at the meetings, overheads, etc. Text files, Microsoft Word documents and PowerPoint documents are the three most common ways of providing information. Combine the minutes and all related documents in a single .ZIP archive and upload it to the website.

If your WG did not achieve quorum, post a document stating that fact and that no business was conducted.  While there can be no binding decisions on calls that do not achieve quorum, minutes of the discussions, should there be any, should be taken and posted to the website.

The posting of minutes is a WG Health Metric.

Co-chair Utility Page

Templates and other helpful instructions are available on the HL7 Essentials space. The page has links and documents related to Balloting, File Maintenance Utilities, Reports, and Robert’s Rules.

Work Group Meetings (aka Conference Calls)

Work Group Co-chairs will schedule online meetings on a regular basis to conduct the work of the Work Group outside of the three Working Group Meetings held each year.  It is not uncommon for a Work Group to have a meeting of the full Work Group as well as smaller project focused meetings or sub-group meetings on a regular basis - it may be weekly, bi-weekly or monthly.  All meetings must be scheduled using the HL7 Conference Call Center to ensure that there is visibility of the ongoing meetings.

Conference Call Center

As a WG Co-chair, you will need to schedule a conference call at some time to discuss WG business. 

The conduct of business via conference calls between WGM is a WG Health metric.

Conference calls are scheduled via the conference call center.  These may be scheduled to discuss business that was left over from the Working Group Meeting, to continue ballot reconciliation, or simply to agree on the agenda for the next meeting.  Some groups schedule recurring calls every Monday at 10 am EST, for example, or every other Wednesday at 2 pm EST.  The conference call number and access code(s) are included in the meeting invite.

How to schedule your call

Use the on-line conference call center.  The call center allows you to schedule single (one time occurrence) or recurring (every week) calls for your WG.  You can also edit, cancel and delete calls using the Conference Call Center. 

Normally conference calls can only be scheduled through the next two WGMs and should be rescheduled during or immediately following a WGM so they are calendared on a continuous basis.  For example, if the next WGM is the first week of May, after January 13th, you can request calls through the first week of October which is one month following the last day of the September WGM.

The Process for Conference Call Center Setup

  1. Go to the Conference Call Center
  2. Use the navigation to add the type of call you want to request either one time or recurring
  3. Make sure to select the list service that will be used by this call for automated messages
  4. Your call is now online and  will be tied to a dial-in and access number
  5. A reminder for each call will automatically be sent to the list associated with the call one to two days (1-2) days prior depending on your time zone.

Conference Call Center Features

On-screen tips are available to help while you learn the new interface for call scheduling.  It is a straightforward guided system similar to ones you probably already use.

    • You can “name” your call when submitting a request.  This enables topic or event driven calls to be obvious on the calendar.  You should not name a call if the call is just a routine call (or a recurring series of calls) for a group.  This is meant as a phrase for WGs (for example the EHR publishing group), not as an agenda description.  There is a place provided for agendas.
    • If you have the privileges needed to schedule a call, you have an option to “secure” a call.  Because everything you see on the calendar is public domain, securing a call is necessary for executive level committees.  For WG calls the use of this function is discouraged.
    • If there are multiple list services available for the working group you have selected for a call, you can choose the list that reminders will go to.
    • Reminders for calls will automatically go out to the assigned list one to two days (1-2) days prior depending on your time zone.
    • You can change basic information for an individual call, even if it occurs as part of a series of calls.
    • Individual calls can be cancelled and an automatic reminder will go to the list to which that call has been assigned.
    • You must have access privileges as a co-chair, Board Member or HQ Staff in order to request a call
    • Do not “name” your call if the call is for a WG (see conference call features for information on naming a call) rather than a specific event.  There is agenda space provide for these kinds of details
    • Do not forward your confirmation of a scheduled call to remind people of the call which happens automatically.  Additionally, there is a manual reminder option should events dictate.
Conference Call Reminders
    • You must have access privileges as a co-chair, Board Member or HQ Staff in order to request a call
    • Do not “name” your call if the call is for a WG (see conference call features for information on naming a call) rather than a specific event.  There is agenda space provided for these kinds of details
    • Do not forward your confirmation of a scheduled call to remind people of the call which happens automatically.  Additionally, there is a manual reminder option should events dictate.

Conference Call Cheat-Sheet

It is difficult, if not impossible, to accommodate everyone’s schedule for a conference call, especially with participants from around the world.  If you need to know what time it is in a different country/city, it is suggested that you consult the World Clock.

Provide a desired start time to your call participants along with your access number and participant code which you are provided.

Use of Teleconferencing Services with Screen Sharing

HL7 supports the use of Zoom and Free Conference Call (FCC) for conference calls.  Both of these applications support audio (either via by dial in or via your computer) as well as screen sharing.

If your Work Group uses either Zoom or FCC, you can contact webmaster@hl7.org to have the dial in information and web meeting information in Conference Center updated for either Zoom or FCC.

Use of Zoom

For more information on how to use Zoom, see Zoom Tip Sheet on Confluence.

If your Work Group is not currently using Zoom, you can sign up Work Groups Migrating to Zoom

Use of Free Conference Call (FCC)

For more information on how to use FCC, see Free Conference Call Tip Sheet

Co-Chair Expectations

Co-chairs are expected to attend all WGMs.  Obviously, there will be occasions when you cannot, for work or personal reasons, attend.  But generally, you should plan on attending all WGMs.  

Refer to the DMP and Robert’s Rules sections of this handbook for tips on ensuring successful meetings. 

  • Arrive in time to meet all of your commitments as co-chair of your WG and to check over your meeting room. 
  • Attend the Monday night co-chair meeting at the WGM.
  • Announce your agenda at your meeting. It is good practice to do introductions each quarter at the WGM. This helps new attendees become familiar with your work group and its members/participants and allows new attendees to be introduced to the larger group.
  • Before adjourning your session at the WGM, work with your group to define a preliminary agenda for the next WGM or conference call; preferably no later than Wednesday of the current WGM.

Keeping WGM Attendees Updated on Agenda Changes

Occasionally, WGs need to change their agendas or cancel or add meetings.  To ensure that all WGM attendees are kept up to date on these types of changes, co-chairs are required to make announcements regarding these types of changes in a time frame that aligns with the group's DMP.

To ensure that these types of changes are communicated to all attendees, co-chairs are required to post these announcements:

  • to their WG listserv, and
  • on the bulletin board near the WGM registration desk. (NOTE: while meetings are virtual, announcements are posted via Whova)

Additionally, co-chairs may also wish to make these announcements via the HL7 mobile app.  You can arrange for this type of announcement by contacting HQ staff. Announcements must be done using multiple methods to ensure that all attendees are notified.

Relationships outside HL7

Relationships with outside organizations are managed by the Board of Directors.  Co-chairs should refrain from inviting outside organizations to meet with a particular WG without approval from the HL7 Board of Directors. 

Appointment of Acting Co-Chair as Needed

Infrequently, there may be occasions when no co-chairs from your WG will be available to attend a WGM.  For these occasions, WGs may appoint an acting co-chair by bringing a formal motion to the WG in advance of the WGM.  GOM §08.03 Majority Rule allows for any formal motion (including one to appoint an acting co-chair(s)), to be brought for vote to the WG using its DMP. 

Acting co-chairs shall have all the powers, privileges, and responsibilities of an elected co-chair for a specific period of time with no expectation of election.  An acting co-chair would typically be appointed to preside over the WG sessions at a WGM.  The co-chair powers, duties and responsibilities revert back to the elected co-chairs at the conclusion of the WGM.

HL7 has a formal process for electing co-chairs, which include a 45-day call for nominations and elections during the month of July.  Occasionally, a co-chair will resign at a point in time that occurs after the 45-day call for nominations.  When this occurs, WGs may select an interim co-chair by a vote of hands during their WG meeting.  The interim co-chair will serve until such time as a formal election can be announced and held.   Unlike an acting chair, an interim chair has all the powers, privileges and responsibilities until the formal election is held.  Many times, the interim chair anticipates being elected during the formal election period. Interim co-chairs will be added to the appropriate list servers and web pages.



Chapter 3 Work Group (WG) Planning


FOREWORD

Much of the guidance from the TSC to the Work Group Co-Chairs can be found on HL7.org under resources, then select TSC Guidance and on the HL7 Essentials Space.

Co-Chair Division of Labor

Each WG will typically be led by at two or more co-chairs.  Each WG has unique projects and needs; the division of responsibilities should be approached with that in mind. For instance, for those WGs whose work involves both V2 and FHIR, it is advisable to divide responsibilities between the co-chairs. One successful model is to specify a V2 co-chair, a FHIR co-chair and an administrative co-chair (who assumes responsibility for meeting minutes and other administrative duties). Dividing the responsibilities in this way ensures that all areas are covered without overburdening a single person. The model of how duties should be divided, should be based on the skill sets of the co-chairs.

Another model, when there are four co-chairs, is to designate/elect both an experienced and new co-chair per version and split administrative duties among the four co-chairs. 

Key Documents for this chapter

Ballot Desktop

Decision Making Practices current template

Governance and Operations Manual (GOM §05.01 Antitrust Policy, §11.02.03 Dissolution of a WG & §11.02.02 merging two or more Work Groups )

Mission and Charter Template

Out of cycle ballot

Publication Request Template 

Standard Withdrawal Template

TSC Guidance

HL7 Essentials

WG Dissolution Template

Work Group Health

Project Proposals

Project Scope Statements

Action Items

WG Mission and Chapter - Every 5 years

WG SWOT Statement - Every 5 years


Engaging with the Technical Steering Committee

In addition to chairing the WG, co-chairs are expected to engage with the TSC via the Working Group Representatives to the TSC. The Working Group Representatives are the conduits of communication from the TSC to the WG co-chairs.  

Assuming Stewardship for the Work Group Page on the HL7 Web Site

Any updates to your WG page should be conveyed to the webmaster (webmaster@HL7.org). Some guidelines for what information must be kept up-to-date are available from the monitoring done in the WG Health Metrics which includes historical metrics and description of their measures.  This includes approved changes to your mission/charter statement (which requires TSC approval), changes to your contact information, Decision Making Practices (DMPs), etc.

Keeping WG Mission and Chapter Up to Date

Every 5 years

Co-chairs should ensure that their WG’s mission and charter statement is kept up-to-date.  Mission and charter (M&C) statements must be reviewed periodically, at least every five years as reflected in WG Health Metrics, with or without updates made. During this review, the WG M&C should also be compared to the current M&C template to maintain consistency with the current format.  Approved, updated M & C are sent to the TSC for review and approval (send email to TSC Project Manager). If no updates are made, please indicate to the TSC Project Manager that the M & C was reviewed and no changes made. The updated M&C (if needed) and the review date will be updated on the WG's web site by the WebMaster after approval by the TSC.

A WG may have informal relationships with a number of organizations.  For example, a WG may have several active projects, which in turn may identify early adopters or organizations that are working with HL7 to develop a standards document.  These are informal relationships that are and should be identified in project scope statements; these should not  be listed in the Formal Relationship portion of your WG’s mission and charter statement.  Occasionally a WG, such as Imaging Integration, may be formed in collaboration with another standards group or organization. These relationships are formalized with a Statement of Understanding (SOU) or Memorandum of Understanding (MOU).  A list of these formal relationships is available. Please note the requirement at relationship.

Keeping WG SWOT Statement Up to Date

Every 5 years

Co-chairs should ensure that their WG's SWOT (strengths, weaknesses, opportunities and threats) documentation is kept up-to-date, not to exceed five years old. The presence of a current SWOT statement is a Work Group Health Metric.  The updated SWOT should be posted on the WG Confluence Space.

Posting Agendas, Minutes and Documents

WG agendas, minutes and documents should be posted on the WG's Confluence Space.

Click "Show More" and scroll to find the "Teleconference Agenda/Meeting Notes" Template. 

The minutes should include:

  1. A list of attendees
  2. Antitrust Statement: The following must appear in the agenda/minutes, but is not required to be read out. "Professional Associations that bring together competing entities, such as HL7, are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 activities, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust policy as stated in §05.01 of the Governance and Operations Manual (GOM)."
  3. Precisely worded motions that were made along with indication of how successful they were (passed unanimously, passed without objection, or the actual number of votes for, against, and abstentions).  Motions and tallies related to ballot reconciliation can, instead, be recorded in the reconciliation spreadsheet, and posted as noted under item 5 below.
  4. Descriptions of any associated work products (white papers, draft documents, presentations, etc.).
  5. The agenda for the next meeting
  6. Electronic copies of all work products of the WG including papers that were presented at the meetings, overheads, etc. Text files, Microsoft Word documents and PowerPoint documents are the three most common ways of providing information. Combine the minutes and all related documents in a single .ZIP archive and upload it to the website.

If your WG did not achieve quorum, post a document stating that fact and that no business was conducted.  While there can be no binding decisions on calls that do not achieve quorum, minutes of the discussions, should there be any, should be taken and posted to the website.

Your WGM meeting minutes are expected to be posted within two weeks following the WGM. Conference call minutes should be posted as defined in the Decision Making Practices document. 

The posting of minutes is a WG Health Metric.

WG Reports

A number of reports are provided to WGs to help manage projects, ballots and published specifications.  Reports can be accessed from the WG’s webpage on HL7.org via the “reports” Tab:

    • Active Ballots
    • Active STUs
    • Active Informatives
    • Active Ballot Items without Reconciliation Package Posted
    • Idle Ballot Items
    • Expired or Expiring STUs
    • PBS Metrics Reports

Prior to each WGM, a PBS metrics report is provided in a spreadsheet format. It is expected that WG co-chairs will review the content for their WG and work to resolve any identified issues (for example, projects behind in milestone dates, expired or expiring STUs, active ballots without reconciliation packages, etc.  If you identify an issue with any of the reported metrics, you can contact the TSC Project Manager (tscpm@hl7.org).

Chair All Meetings and Conference Calls of Your WG

Refer to the DMP (and your WG's DMP addendum) and Robert’s Rules sections of this handbook for tips on ensuring successful meetings.  

Roberts Rules of Order

The following documents relate to Robert’s Rules of Order; a guide to parliamentary procedure:

Other Work Group Concerns

Dissolution of a Work Group

GOM §11.02.03 defines the process for Dissolution of a WG. The WG Dissolution Template referenced in the GOM is available online. Additional information is available by clicking below.

Given approval under the Work Group’s documented decision making practices, the co-chairs shall complete and submit a Work Group Change Request to the TSC Chair and CTO for dissolution of the Work Group. Reasons for considering dissolution include lack of interest or expertise as evidenced by participation consistently falling below five members or achievement of the objectives of the Work Group. The request should seek to identify those Work Groups that might assume the work of the dissolving Work Group. The TSC Chair and CTO may propose and seek alternatives to dissolution.

With the concurrence of the TSC Chair and CTO, the dissolving Work Group co-chairs shall seek the approval of the appropriate Work Group(s) to assume responsibility for their work products. The Work Group(s) shall confirm consent by a two-thirds affirmative vote of their members casting a vote. The dissolving Work Group co-chairs shall complete and submit the Work Group Change Request to the TSC. The results of the attempt to achieve consent for the assumption of work products shall be reported on the request.

The TSC Chair shall distribute the request to all other Work Group co-chairs and schedule a vote of the Work Group co-chairs to consider the request for dissolution within 30 days of submission. If appropriate, all Work Group co-chairs shall petition their Work Group members for candidates to join the affected Work Group in an effort to forestall its dissolution. Should sufficient members come forward, the request to dissolve the Work Group is moot.

Upon an affirmative vote by two-thirds of the parent Work Group co-chairs casting votes with at least 60% of the Work Groups returning a vote, the TSC Chair shall submit the request to the TSC for review of the request for dissolution within thirty days. The TSC shall address the request to dissolve under the tenets of its documented decision-making practices. Upon approval, the TSC Chair shall notify the Board of the dissolution of a Work Group and the disposition of that Work Group’s work products; the HL7 staff representative shall request that Headquarters take the appropriate actions to effectively remove the Work Group from the organization.

Merging Work Groups

GOM §11.02.02 defines the process for merging two or more Work Groups. Additional information is available by clicking below.

Two or more Work Groups (WG) may, for whatever reason and following their documented decision making practices, decide to consolidate their membership and work items. Upon such a decision, the members of the WGs involved shall designate one of the WGs as the surviving WG. Subsequently, the co-chairs of the dissolving WG(s) shall complete and submit a Work Group Change Request for dissolution [§11.02.03] citing the proposed merger. Concurrently, the co-chairs of the surviving WG shall complete and submit a Work Group Change Request to change the name of the WG and its mission and charter [§11.02.01] citing the proposed merger. Upon approval of the request to dissolve and request for name/mission and charter change, the consolidated WG shall undertake a reconciliation of their former respective DMP with the objective of establishing a comprehensive DMP for the consolidated WG.

Responsibilities for Intellectual property

HL7 retains the intellectual property for HL7 material.  The requirement to restrict access to HL7 standards, including draft material or work in progress material to HL7 members and Affiliate members was removed on November 4, 2019.  Draft specifications or pre-ballot materials are no longer required to be restricted to “members only” by posting them on the Work Group website under “members only” access.

Work Group White Papers

A WG may, on occasion, decide to prepare and publish a white paper; i.e. an authoritative report or guideline informing readers in a concise manner about a complex issue and presenting the issuing body’s philosophy on the matter.  A white paper is meant to help readers understand an issue, solve a problem, or make a decision. 

A white paper, as with any other HL7 publication, shall be initiated via a Project Scope Statement (PSS) and follow the prescribed project approval process.  The scope and intended audience of the white paper are factors that affect its processing and publication. 

  • A white paper purported to represent a  Work Group(s) position on an issue or resolution and intended for a specific interest group may, at the WG’s discretion, be approved following WG peer review, which may be undertaken via the WG list server or Confluence.  A Work Group White Paper (WGWP) shall use the WGWP Template and be published on the WG web page under “Documents” and/or the WG Confluence space, but shall not appear in the Master Grid of Standards.  Upon Work Group approval, the responsible WG co-chairs shall post the WGWP to the WG web page under <documents><white papers>.  The HL7 site will include a new page under <Resources> that will display WGWP by WG.  WGWP shall be subject to reaffirmation or withdrawn within five years of publication, by simple majority vote of the Sponsoring Work Group.  Co-chairs shall ensure that appropriate action is taken on or before the five year anniversary.
  • A white paper purported to represent an  HL7 position  on an issue, decision, or resolution shall be approved via an Informative Ballot and shall appear on the Master Grid of Standards.  Upon Work Group approval, the responsible WG co-chairs shall submit the white paper for consideration for publication using the Publication Request Template.  Informative white papers shall be subject to reaffirmation or withdrawal within five years of publication, last update or last reaffirmation following the same process as current balloted HL7 artifacts.  Co-chairs shall ensure that appropriate action is taken on or before the five year anniversary.

Review of HL7 Projects

The WG is responsible for reviewing projects either proposed or being undertaken by other HL7 Work Groups.  It is suggested that WGs establish a routine of reviewing all project proposals and project scope statements (PSS) as part of their teleconferences and to provide feedback.  

Project Proposals

Project Proposals are required for any potential project where the specification or artifact(s) have never been published in HL7 BEFORE a Project Scope Statement (PSS) is created.  The purpose of the Project Proposal is to:

  • Provide early insights into potential projects
  • Prevent "shopping" around of projects to find a sponsor
  • Seek sponsor and other interested parties
  • Identify overlapping projects in other Work Groups or outside of HL7
  • Identify projects that are outside of the mission of HL7 at an early stage.

When a new Project Proposal is created in Jira, WG Co-chairs will receive an email.  The Proposal is open for a 2 week review and WGs are expected to review the Proposal to determine if it is a potential project that is relevant to the WG and provide a comment.  The Proponent is expect to respond to all comments before it is referred to the TSC to accept or reject the proposal.  Read more on how to create and review a Project Proposal.

Project Scope Statements (PSS)

Effective November 1, 2021, all Project Scope Statements, except those for reaffirmations and withdrawals, must be created in Jira.  Reaffirmation and Withdrawal PSS will continue to be created in Confluence.  

Guidance on how to review a PSS in Jira




Chapter 4 - Project Management

WGs are expected to follow HL7’s project management methodology as described in the HL7 Essentials. This includes:

  • Creating a project proposals (for new WG projects only). The Project Proposal is created by the sponsoring Work Group or an individual with an idea of a project to be done in HL7. This is broadcast to all co-chairs and is intended to identify a sponsoring Work Group (if there isn't one) and other interested parties.  This is a two-week review process.
  • Creating  and seeking approval of the project scope statements (PSS) (for all WG projects). This involves multiple steps over the course of several weeks:
    • Step 1:  Create a Project Scope Statement (PSS)
    • Step 2a:  Sponsoring Work Group reviews/approves the PSS; upon approval, send to PMO
    • Step 2b:  Submit PSS for Administrative Review/Approval:
      • Co-Sponsor

      • US Realm Steering Committee (USRSC)

      • Family Management Group(s)

      • CDA
      • FHIR
      • V2
    • Step 3:  PMO enters the Project Scope Statement into Project Insight
    • Step 4: Submit PSS to TSC for review/approval
    • Step 5: The HL7 PMO ensures that HL7 project methodology is adhered to
  • Maintaining project status in HL7’s project management tool, Project Insight. As the project progresses, WGs should keep milestone and other relevant information updated in Project Insight.

Each WG should recruit a project facilitator when possible, to assist in these tasks, either for the WG projects in total, or on a project-by-project basis. 

Project Scope Statements (PSS)

Effective November 1, 2021, all Project Scope Statements, except those for reaffirmations and withdrawals, must be created in Jira.  Reaffirmation and Withdrawal PSS will continue to be created in Confluence.  Read more on how to create a Project Scope Statement in Jira.

Reaffirmation and Withdrawals

For information on creating a PSS in Confluence

PSS Deadlines

There are a number of deadlines for Projects that WG Co-chairs need to keep in mind:

  • Submission to a WG approved PSS to the Project Management Office (PMO) - 2 weeks after the Friday of the WGM TWO PRIOR to the ballot cycle
  • TSC approval - 4 weeks prior to the Sunday of the WGM ONE PRIOR to the ballot cycle

That means if you want to ballot in the September 2022 Ballot Cycle:

  • WG approval for the PSS must be completed by February 4, 2022
  • TSC approval for the PSS must be completed by April 17, 2022

The PMO sends a reminder email with the relevant dates for the upcoming ballot cycle to WG co-chairs each month.  You can refer to the HL7 Calendar for the relevant dates for a given ballot cycle.

Appeal Process for Missed Deadlines

If you miss either of the deadlines above, you can appeal to the TSC by submitting an appeal to tscpm@HL7.org.  You must include the PSS and a detailed rationale why your project must be included in the ballot cycle despite missing the deadline or deadlines(s).


Project Artifacts

Project Insight

Project Insight is HL7’s Project Management System.  Each WG has been assigned a log-in available from the WG co-chairs or the HL7 Project Management Office (PMO): PMO@HL7.org.

Github

Github is the version control system used by Work Groups and project team to assist with the management of specifications and associated artifacts.  To request a Github Repository for a project or a Work Group, submit a Jira Request: Request Github Repository

Three-year Planning

Three-year planning is optional for each WG, and the future work identified should be listed as three-year planning project placeholders in Project Insight.  By using this mechanism, visitors and members using the Project Insight Searchable Database can find reference to upcoming project in which they may be interested. As future development is identified, co-chairs can send their planning project descriptions, which do not require a full project scope statement, to the HL7 PMO office for update. The TSC has provided Three Year Planning Guidelines.

Project Conference Calls

Conference calls related to project work must be visible in the HL7 Conference Center and must be open to attendees outside of the project.  This is required to meet the ANSI requirement of open and transparency. It is not acceptable to schedule calls out side of the HL7 Conference.



Chapter 5 - Balloting

Co-chairs are ultimately responsible for ensuring that any material that the WG wishes to ballot is completed as required and in a manner that is consistent with procedures upheld by the TSC following Publishing guidelines.

Participating in Publishing

Each WG is encouraged to select an individual who will function as the WG publishing facilitator or editor and participate in the Publishing WG. A list of current publishing facilitators is available.  Please contact Headquarters (HQ@HL7.org) if your WG changes the publishing facilitator so that we can keep this list updated. The individual selected to function as the WG editor should join the editor’s list server and contact the chairs of the Publishing WG for additional instructions.

Participating in Vocabulary Maintenance

Each WG is encouraged to select an individual who will represent, monitor and vote on relevant requests for changes to HL7 terminology maintained in the Unified Terminology Governance (UTG) process.   For more information, review Vocabulary Maintenance at HL7.

Some HL7 artifacts may reference eternal terminology. Questions or updates related to external terminology should be directed to the HL7 Terminology Authority (HTA).

The HTA  serves as the single point of contact for any external terminology which is referenced in any HL7 artifact.  It also supports establishment and maintenance of formal relationships between HL7 and terminology providers, which are governed by Statements of Understanding (SOU) between HL7 International and such organizations as endorsed by the Executive Committee.   The HTA works with both the Vocabulary Work Group, responsible for technical terminology structures in HL7 Specifications, and HL7 Unified Terminology Governance, responsible for managing HL7-authored terminology and Terminology@HL7.org (“THO”) which provides the authorized metadata needed to reference external terminologies in HL7 artifacts.

HTA responsibilities include:

  • Maintaining relationships with external terminology providers to ensure legal use of their products
  • Working with external terminology providers to get the correct metadata to reference the use of their products in HL7 artifacts
  • Providing advice, where needed, on the acceptability of external vocabulary proposed for inclusion in HL7 terminology


Key Documents for this chapter

Amalgamation Macro

HL7 Essential Requirements (ER §02.10.04 substantive change)

Governance and Operations Manual (Electronic Ballots (GOM §13); Informative Documents (GOM §14.01); Standards for Trial Use (STU) (GOM §14.02); and Comment-only (GOM §14.04) )

Publishing Facilitators

Recirculation Request Template

Vocabulary Maintenance at HL7

How to Documents

Reconciliation How-To Document

Action items

HL7 Calendar


Managing Suggested Updates and Modifications to the Standards

Keeping track of suggested enhancements and technical corrections/typographical errors was once a time consuming and often overwhelming task.  To assist co-chairs with this task, 4 projects in Jira have been created to capture feedback related to the product families and all other specifications. 

Comments are captured in these Jira projects and WGs should be using these projects to manage ballot reconciliation.  There is a mechanism to import ballot spreadsheets into Jira which should be used.  See Confluence for more information on importing spreadsheets: https://confluence.hl7.org/display/HL7/Importing+ballot+results+from+spreadsheets

Effective with the January 2022 Ballot Cycle, HL7 transitioned to Jira for balloting (except reaffirmation and withdrawal ballots) and comments captured in spreadsheets will not exist.  All comments will either be entered directly into the Specification Feedback project in Jira or will be imported to the appropriate project by the submitter or organization prior to the close of the ballot. More information on the Specification Feedback projects can be found at https://confluence.hl7.org/display/HL7/Specification+Feedback.

The current process for conducting Review Ballots is found in GOM §14 while the process for balloting normative documents is provided in the HL7 Essential Requirements (HL7 ER).  It is imperative that co-chairs know how to prepare for and conduct ballots.  ANSI auditors select a given number of normative ballots for review every five years.  The auditors are very thorough and will check to ensure that every negative balloter/commenter has been advised in writing of the status of their negative vote/comments and that each negative vote has either been withdrawn or addressed in a recirculation ballot, and that each negative balloter is informed of the appeals process.

An annual HL7 ballot schedule, based on three ballot cycles per year is published.  All ballot types will adhere to the ballot schedule unless granted an exception by the TSC.  The ballot schedule is distributed to all co-chairs and identifies all critical path dates regarding preparation and submission of ballot material.  All ballots must be approved by the TSC. The HL7 calendar is available on Confluence.

Ballot Desktop

HL7 uses the Ballot Desktop for ballot pool/consensus group sign up and to store vote totals and reconciliation packages for each of its ballots.  Prior to the pilots of Jira Balloting in 2021 and the move to Jira for all balloting (except reaffirmation and withdrawal ballots) in January 2022, the Ballot Desktop was used to store votes, comments and reconciliation packages for all ballots.  With Jira Balloting, the comments are captured in the Jira Specification Feedback Projects (FHIR, CDA, V2 and OTHER). The Ballot Desktop enables co-chairs to view ballots related to current and past ballot cycles, send email to voters in the consensus groups related to their WG ballots, and post reconciliation spreadsheets that advise the voters of the status of negative votes. All ballot types, be they Review and Normative, are handled by the Ballot  Desktop.

More information on Jira Balloting: Jira Ballot Process

Review Ballots

There are three types of Review Ballot:

  • Informative Documents (GOM §14.01);
  • Standards for Trial Use (STU) (GOM §14.02); and
  • Comment-only (GOM §14.04). 

The flow involved in the review ballot process is depicted in the following diagram.

The following describes the types of ballots:

  • Informative Documents explain or support the structure of HL7 standards, or provide detailed information regarding the interpretation or implementation of an HL7 standard.
  • STU are normally issued as a precursor to a normative ballot.  They allow the responsible WG to gather industry input on the completeness and viability of the implementation of a proposed standard.  The review ballot allows for validation of the content of the proposed standard prior to release for trial use. 
    • For FHIR Implementation Guides, the testing requirement (connectathon or other type of testing) must be met to ballot as STU
  • Comment-only review allows the WG to gather input from a broader audience on documents in process; be they requirements documents, possible informative documents, or candidates for normative status.  Comment-only ballots are also used to validate certain administrative actions such as assessing the membership’s position on the proposed withdrawal of an informative document or normative standard.

Although the TSC may approve multiple iterations, typically there is a single occurrence of a given Comment-only ballot since the next step for the document under review would be an informative, STU, or normative ballot.  An informative document or STU review ballot may remain active until the content is either approved or withdrawn.

HQ notifies all current members at least 30 days prior to scheduled ballot open date of the intent to form a consensus group for Review Ballots.  Consensus group signup is allowed until the day prior to the date that the ballot opens.

In the course of the ballot period all comments should be captured via the Ballot Desktop to facilitate later consideration by the WG.

There is no reconciliation of review ballot comments per se.  However, WGs are expected to consider all comments with the intent of improving the quality and clarity of the content being reviewed.  The results of the WG’s consideration of each comment shall be recorded on the Ballot Desktop.  There is no requirement to resolve negative comments.

Substantive change as a result of a review ballot does not cause an arbitrary need to conduct another review ballot.  Such changes are the result of identifying obvious shortcomings in the ballot content which is the intent of a review ballot.  Having incorporated the change, the WG may move forward with the informative document or STU.  However, a WG always has the option to conduct another review if felt necessary.

Quorum and approval levels differ by review ballot type.  Please consult the GOM for specifics.

Where the evaluation and comment period of a STU results in a need for substantive changes to the proposed standard, the resulting normative ballot material may embody such changes or a revised STU may be released for further evaluation and trial use without recourse to another review ballot.

Normative Documents

A normative ballot is used to validate and approve proposed American National Standards (ANS).  The normative process is driven by American National Standards Institute (ANSI) requirements as implemented by the HL7 Essential Requirements: Due process requirements for HL7 American National Standards (HL7 ER).  

The FHIR Management Group requires that FHIR Implementation Guides have met testing requirements (connectathon or other) prior to balloting as normative.

The following diagram outlines the overall process for Normative Ballots.

HQ notifies all current members at least 30 days prior to scheduled ballot open date of the intent to form a consensus group for normative ballots.  Consensus group signup is allowed until the day prior to the date that the ballot opens.

Co-chairs should monitor ballot responses as they are submitted (co-chairs receive copies of all returned ballots related to their WG) and notify the consensus group, especially those who returned negative ballots, when and where their comments will be discussed; e.g., Monday-Wednesday at the next WGM including the location and date.

The following tasks are required to support reconciliation:

  • A preliminary reconciliation package should be prepared and distributed at the meeting, via email or posted to the Ballot Desktop that lists each negative vote/comment and a motion for resolving it.  HL7 provides an Amalgamation Macro to aide this process.
  • Open discussions should be held to determine the disposition (by WG vote) on all negative comments received in response to the ballot. This may be accomplished at the WGM, via a conference call, etc., but should be consistent with what was announced above. 
  • Motions and subsequent votes should be recorded in the disposition section of the Ballot Comment Spreadsheet and include as a zip file with the meeting minutes. The different dispositions are:
    • Persuasive: A majority of the WG agrees without objection that the position expressed by the negative response is persuasive; the changes recommended by the comment shall be incorporated as reasonable and necessary revisions.
    • Not Persuasive: A majority of the WG agrees that the comment deals with process or issues not under the control of the WG, or suggests the use of alternate methodologies or solutions which have no advantage over those used, or questions the validity of the approach or the expertise of the developers.  Comments declared not persuasive but not withdrawn are reported as unresolved negatives.
    • Not Related: A majority of the WG agrees that the comment deals with issues or functions beyond the scope of or is clearly not related to the ballot subject matter.  Comments declared not related are reported as “negative without comment” and don’t impact the outcome of the ballot.

Once the WG has voted on the dispositions, post the latest version of the Ballot Reconciliation Spreadsheet and send an e-mail through the Ballot Desktop to each negative submitter advising them of the status of their negative vote/comment.  HL7 HQ must be able to produce this communication for the ANSI auditor.  Using the Ballot Desktop ensures that this requirement is fulfilled and that the communications are captured in a central location.

Follow up with each negative voter to ensure that he/she has been informed of the disposition of their negative vote and given an opportunity to either withdraw the negative vote (which becomes a positive vote) or affirm the negative.  To withdraw a negative vote, the voter must advise the co-chair and the appropriate HL7 staff in writing, which is typically done through the Ballot Desktop.

Following reconciliation, determine if the document passed: a majority of the consensus group returned a ballot representative of a majority of HL7 members enrolled and at least 75% of combined affirmative/negative votes are affirmative.  Unresolved negative comments do not preclude a document from being submitted to ANSI; however, submission with unresolved negative comments must be preceded by a recirculation ballot to allow consideration of such comments by the entire consensus group.

Make any updates to the document and notify HQ of your intent to re-ballot, if substantive changes merit such, or move forward to ANSI for approval.

For a subsequent normative ballot of the same content, the consensus group shall include those who responded to the previous ballot; whether affirmative, negative, or abstain.  Although the TSC may re-open the consensus group to additional registrants, typically the consensus group for subsequent normative ballots of the same content is not open to additional signup.

In the case of a subsequent normative ballot of the same content, a negative vote or comment that has been previously considered and resolved  and is resubmitted does not require further consideration.

Reconciliation Activities

Co-chairs are responsible for tracking, completing and posting Ballot reconciliation items using the Ballot Desktop.  It is very important that ALL reconciliation activities be recorded on the Ballot Desktop.  If at any time you need support in correctly using the Ballot Desktop or in troubleshooting problems you might have, please contact the Technical Publications Manager (ballotmanager@HL7.org) and Webmaster (webmaster@Hl7.org) for help.  For specific instructions on completing the Excel-based reconciliation spreadsheets, please refer to the instructions in the reconciliation spreadsheet template.  In general, co-chairs are responsible for:

    • Consolidating all comment spreadsheets submitted on their ballot document during the ballot period before the WGM using the Amalgamation Macro - Effective with January 2022 Ballot Cycle, all comments will be captured in Jira Specification Feedback and not in spreadsheets for ballots other than reaffirmation and withdrawals.
    • Conducting reconciliations during WGMs and conference calls
    • Recording and tracking the WG reconciliation decisions and actions in the appropriate Jira Specification Feedback Project
    • Posting the completed reconciliation package to the Ballot Desktop
    • Notifying all negative voters of the status of their negative votes using the Ballot Desktop

It is recommended that co-chairs post an amalgamated spreadsheet before beginning reconciliation so all participants have access.  As reconciliation activity proceeds, post incremental updated spreadsheets using version numbering (V1, V2, etc.) or including the “effective date” in the title.  These posting should be to the Ballot Desktop; if not, you must ensure that all participants are aware of their location.  When reconciliation is completed, it is recommended that the term “final” be included in the title of the spreadsheet.

Completion of reconciliation activities is required for all Normative Ballots to meet ANSI requirements.  Co-chairs may find the reconciliation how-to document helpful when undertaking reconciliation activities.

Consolidation Comments

At the close of the ballot period a co-chair should log in to the Ballot Desktop and consolidate all the comments received from voters during the ballot period.  These actions should be completed prior to the upcoming WGM so that WG members have the consolidated comments spreadsheet available for review during your sessions at the WGM.

1)      From the Ballot Desktop, click on the Tally tab.  When the screen refreshes, you will see a listing of all the consensus groups with each title linking to an individual Tally page.

2)      Click the link for your WG’s ballot document.  This will load the Tally page for your ballot document.  In the left-hand menu section titled "Participation Summary Download" are links to help you download summary information and create a consolidated comment spreadsheet.

3)      To begin, click on the Export this Ballot Participation Summary Information link.  You will be prompted to open or save a "CSV" file.  Click the Save button and save the file to a convenient location, such as an appropriately-named folder on your desktop.  (More information on saving and formatting this "CSV" file as an Excel spreadsheet can be found from the Tally page by clicking on the Instructions for Using the Exported data link.)

4)      You should also download the Participant Summary Download Macro spreadsheet from the Tally page to the same location you saved the "CSV" file.  When you open this spreadsheet it will prompt you to select the "CSV" file.  Macros in the spreadsheet will then format it and allow you to save it as an Excel file.

5)      Continue to download all the comment spreadsheets submitted by voters to the same download directory.  The Tally page will display a link to each of these files in the "Upld?" column.

6)      Once you have collected all the Comment spreadsheets, you will need to consolidate them into a single spreadsheet.  This is done with the Ballot Amalgamation Macro Spreadsheet.  A link to this spreadsheet is available from the main Tally page that lists all the consensus groups.  Full directions on performing the consolidation are included in the spreadsheet.  Please note that not all voters will provide their comments in a Comment spreadsheet; some may use a Word file or provide comments with their votes.  You will need to manually add such comments to your consolidated comment spreadsheet.

7)      Use of the Ballot Amalgamation Macro Spreadsheet may result in links from the consolidated spreadsheet back to the original spreadsheets.  These links are maintained by Excel and may produce annoying notices when opening the spreadsheet regards updating the document from the linked document.  If Excel is set to update those links automatically there is the possibility of locking up Excel while it attempts to do the updates.  To break the links to the other spreadsheets, open the consolidated spreadsheet and do the following: [IMPORTANT: When a link to a source is broken all formulas that use the source are converted to their current value.  For example: the link =SUM([Budget.xls]Annual!C10:C25) would be converted to =45. This action cannot be undone; it is recommended that you save a version of the spreadsheet before you start. NOTE: these links are different from hyperlinks embedded in a cell.]

7.1 On the Edit menu, clink Links

7.2 In the Source list, Click the link you want to break or select multiple liked objects hold down CTRL and click each appropriate link or to select all links press CTRL + A

7.3 Click Break Link

Guidance on managing Block Votes

What is a Block Vote?

A block vote is a way of grouping a set of Jira Issues for review and voting.  The group of issues is distributed for review to stakeholders in advance of a Work Group call.  Stakeholders can ask that individual issues are removed from the block vote if further discussion is needed on the proposed disposition.  During the teleconference all of the issues in the group or "block" that have not been removed are voted on as a single set of issues.

What process should be used for a block vote?
    • Identify the group or block of issues - tag the issues in Jira using a label (for example, Block-Vote-1)
    • Create an announcement to stakeholders that includes:
      • Describe the purpose of the block vote
      • Include a list of the issues that are included in the block vote
        • Summary
        • Reporter
        • Proposed Resolution
        • Link to Jira issue
      • Information on how and when to request that an issue is removed from the block vote
      • Date and time of the Work Group meeting where block vote will be reviewed
    • Distribute the information about the block vote via the WG ListServ and optionally on Zulip via appropriate stream at least one week in advance of the meeting
    • If there are requests for issues to be removed from the block vote:
      • remove the label on the Jira issues
      • make arrangements with the commenter (Reporter) and other stakeholders to identify a day/time when they can join the Work Group meeting to discuss
    • During the appointed meeting, resolution of the block vote should be done via the usual WG decision making practices

Tracking Reconciliation Activities in the Reconciliation Spreadsheet

During your WG sessions or calls, use the consolidated comments spreadsheet to record decisions for each of the comments listed.  Information should be as complete as possible because the reconciliation spreadsheets provide the primary means of recording WG decisions, of communicating those decisions and the supporting rationale to negative voters, and of tracking any activities by individuals to resolve those negative comments.

Individual columns in the spreadsheet are provided to, among other things, allow WGs to record their responses to comments, to provide a rationale for a decision, to assign a person responsible for completing a reconciliation action, and to record the completion of that action.  Please refer to the instructions in the comment spreadsheet for more help on completing the reconciliation spreadsheets correctly and completely filling in column information.

When your reconciliation actions are complete, compress the reconciliation spreadsheet into a zip file along with any other documentation needed to support the reconciliation actions and decisions.  This zip file and its contents are now referred to as the Reconciliation Package and will be posted on the ballot document Tally page on the Ballot Desktop.

Posting a completed Reconciliation Package

Once a WG has completed all the necessary reconciliation actions to address all negative comments, the completed spreadsheet needs to be uploaded to the Ballot Desktop.

1)      From the Ballot Desktop, click on the Tally tab.  When the screen refreshes, you will see a listing of all the consensus groups with each title linking to an individual Tally page.

2)      Click the link for your ballot document to view the Tally page for your consensus group.

3)      In the left-hand menu, expand the Resolving Negatives header and click on the Upload the Reconciliation Package for the Document Pool link.

4)      The Upload page includes a button to allow you to browse to and select your completed Reconciliation Package.

5)      Once you have selected the appropriate file click the Upload this Reconciliation Package button.  Please note that the web site system will automatically rename your file based on file naming conventions for the ballot pool and the current ballot cycle.  You will receive notification when the file upload is complete.

Notifying Negative Voters of the Status of Negative Comments

Once a completed Reconciliation Package has been posted to the Ballot Desktop, co-chairs are responsible for notifying submitters of the status of their negative comments.  The Tally page on the Ballot Desktop provides functionality to help you complete these actions.

1)      From the Ballot Desktop, click on the Tally tab.  When the screen refreshes, you will see a listing of all the consensus groups with each title linking to an individual Tally page.

2)      Click the link for your ballot document to view the Tally page for your document pool.

3)      In the left-hand menu, expand the Resolving Negatives header and click on the Request Withdrawal by Emailing All Negative Voters link.  This page allows you to email all or select negative voters in the consensus group.  Please note that you either need to select the Send to All Names checkbox or check individual names.  If you don't check any box, the message has no recipients.   
This page also allows you to customize the notification email and to include a link to the reconciliation package in the email.  Co-chairs can use this page to send out several notification emails at different points in the process of completing a ballot.  Such notification might include an initial notification that a reconciliation package is available, follow-up notices if the information in a reconciliation package changes, or requests for additional information from voters who fail to withdraw their negatives.

The completion and posting of reconciliation actions and the recording of reconciliation activities is a very important part of a co-chair's responsibilities and helps us to comply with the requirements of an ANSI-accredited standards development organization.

Escalating and Resolving Requests to Withdraw Negative Votes

As noted above, normative documents can progress to ANSI as long as 75% of the affirmative and negative votes cast on the document are affirmative.  However, unresolved negative votes must be subject to a re-circulation ballot, which presents the members of the consensus group an opportunity to change their vote if desired.  To request a recirculation ballot, complete the Recirculation Request Template and send it to both the Director of Technical Publications and the Associate Executive Director.  If the recirculation ballot concludes with at least 75% affirmative votes, the document can be submitted to ANSI for approval.

Many times, negative voters do not respond to repeated requests to withdraw negative votes or engage with the committee on resolving negative votes. The following steps are recommended to keep the ballot process moving forward:

    • Provide each negative voter with two (2) requests, sent through the Ballot Desktop, to withdraw their negative votes, providing a week or two for a response.
    • If the negative voter fails to respond to those requests, send an email to the Director of Technical Publications and the Associate Executive Director, who will phone the key contact at the appropriate organization and ask the key member to resolve the issue.
    • If the key member fails to respond within a week or two, co-chairs should reassess how many affirmative votes have been received.  If less than 75% of the combined affirmative and negative votes are affirmative, the document may need to be re-balloted.  If at least 75% of the combined affirmative and negative votes are affirmative, the co-chair shall advise the Director of Technical Publications that a recirculation ballot is necessary.
    • If at least 75% of the combined affirmative and negative votes returned for the re-circulation ballot are affirmative, the document will be submitted to ANSI for approval.  If the document failed to pass the recirculation ballot with at least 75% affirmative vote, it is a candidate for re-ballot or withdrawal.

Substantive Change

What is a substantive change?  According to ANSI a Substantive Change is one that directly and materially affects the use of the standard. The ANSI definition includes changes that would break solutions that were implemented using the specification as it existed before the change. As an ANSI-accredited Standards Development Organization (SDO), HL7 must be guided by the ANSI definition provided in ANSI Essential Requirements and reiterated in the HL7 ER. Note that substantive changes are of concern only for normative ballots.

Examples of Substantive Changes are:

    • Changing “shall” to “should” or “should” to “shall”;
    • Addition, deletion or revision of requirements, regardless of the number of the changes.
    • Addition of mandatory compliance with referenced standards

HL7 describes substantive changes as those changes which modify the standard by adding or removing capabilities. Any change that damages the integrity of semantics as well as the validity of syntax is a substantive change. A change that materially affects the contents of exchanged messages is substantive. For example, the addition of a new trigger event is substantive; adding fields to an existing message type is substantive.  On the other hand, the correction of a typographical error, or the addition of an example message is not considered substantive.

HL7 considers a change to the standard to be substantive if an interface would fail when a message composed with the change is built, sent or received. This is similar to, but more expansive than, the definition of backwards compatibility. A change that creates a backwards compatibility problem is substantive by definition.

Role of Substantive Change in Balloting

The goals of the HL7 ballot process are to:

    • Meet its members' needs for specifications that are responsive to conditions. Timeliness is important.
    • Develop specifications that permit any interested HL7 member to participate and make their views known.
    • Encourage early implementation of specifications to ensure that final specifications are used and useful.
    • Publish high quality specifications that are accurate, clear, coherent, and consistent across the full set of specifications.
    • Adhere to ANSI Essential Requirements that are focused on ensuring that a consensus is achieved within the entire industry without any "special interests" skewing the results.
    • Abide by the HL7 Bylaws, Essential Requirements (HL7 ER) and Governance and Operations Manual (GOM) to achieve these goals.

The definition of "substantive" changes must be interpreted within this context.

In a perfect world, every specification submitted for ballot would be complete, coherent, clearly expressed, consistent with all related specifications and delivered "just in time" for its intended use. Normative ballot reviewers would represent the full spectrum of affected parties and would vote in the affirmative with the only comments being small suggestions to add "polish" before publication. Additionally, many people would implement the specifications and actively provide feedback to continue to extend and enhance the specifications.

We realize that we do not live in a perfect world. Each of us juggles many objectives. The tradeoffs are tough and it is the TSC's responsibility to provide guidance to the WGs so that the overall set of specifications approaches this ideal. The TSC should be approached by WGs for interpretation when they cannot clearly delineate changes as either "substantive" or "non-substantive". The 2.x concept of substantive change is based on the premise that changes that would "break" solutions implemented using the specifications are substantive. The TSC this principle to Version 3. Since the goal of Version 3 Standards is semantic interoperability, the overriding principle for determining if a change is substantive will be whether the change damages the integrity of semantics or the validity of syntax. A primary Version 3 principle is the use of constraints as the delineation of correctness. The Version 3 specifications are model driven, so changes to any of the structural properties that would alter the constraints contained in the source models would be substantive changes. Substantive changes for the FHIR specification are defined as changes that introduce new functionality, changes to the specification that create new capabilities, but would not render unchanged existing applications non-conformant.

Effect of Substantive Change

HL7 ER §02.10.04 stipulates that substantive change introduced as a result of comments received on a normative ballot will result in a subsequent normative ballot of the same content.

The Importance of Substantive Change

Why is the distinction between substantive and non-substantive important?  ANSI rules and HL7 process require that all substantive changes to normative material be balloted.

The identification and designation of changes as substantive or non-substantive plays an important role in the balloting process.  When a WG creates a ballot package, the package should include a list of all changes from the previous version of the document.  This list should indicate which changes are considered to be substantive, and which are not.  When a chapter or other section of a standard goes through successive ballots, this list should indicate changes from the prior ballot, not from the beginning of the balloting process.

V2 Substantive Changes description can be found by clicking below.


The following constitute substantive V2 changes:

    • Addition or deletion of a trigger event - This implies the definition of an abstract message corresponding to the trigger event.
    • Addition or deletion of an abstract message or change to an existing one - This includes addition or deletion of segments or segment groups, changes in segment or segment group repetition and changes to segment or segment group optionality.
    • Addition of a segment - This implies the use of the segment in an abstract message.
    • Addition of a data element within a segment.
    • Changes to an existing data element - This includes changes to element repetition or optionality.  It also includes changing the code table assigned to a coded value. When an element is used differently in different segments, e.g. different lengths, this can be addressed as a non-substantive technical correction if the segments are newly conceived.  However, if this is a situation of long standing, fixing it should be considered as substantive.  In this case, the proper tack is to choose a standard length, deprecate the element uses that do not fit, and add the needed elements to the end of affected segments.
    • Addition of a data type - This implies its assignment to a data element.
    • Change to an existing data type - This includes addition or deletion of components, and changes to component order, optionality, or repetition.  It includes changes to the data type assigned to a component, and/or changes in the maximum length of a component.
    • Changes to an HL7 defined table - This implies that the code table is assigned to at least one data element.  Substantive changes include the addition or subtraction of code values.
    • Change to a definition that changes how a receiving system has to manage the received message.
    • Changes to chapter text that change the rules for when a trigger event is used.

V2 Non-Substantive Changes description can be found by clicking below.


The following constitute non-substantive V2 changes:

    • Changes to the codes in user defined and externally defined tables.
    • Changes to definitions (segment, element, trigger event, data type, etc.) that clarify the WG’s intent rather than changing subsequent processing.
    • Technical corrections that implement the original intent of the WG.   For example, if a WG meant to add an attribute to one segment, and it was mistakenly added to another; this can be corrected without an additional ballot.
    • Changes to the HL7 assigned ID for an element when it is realized that what appears to be a new element is an existing one.


V3 Substantive Changes description can be found by clicking below.


V3 Substantive Changes

The objective is the same as for V2 – anyone materially affected by a change in the normative specification should have an opportunity to make their opinion of the change known, and have that opinion taken into consideration, before a change is adopted.

Those potentially materially affected are not just senders and receivers of messages – but consumers of ANY HL7 specification.  Operationally, if implementing against the specification as previously communicated does not accomplish the same objective as implementing against the current specification, the introduced change is substantive.

Substantive differs between Version 2 and Version 3 in the increased emphasis on the “semantics” of the interaction, not just the syntax.  Therefore, if any system participating in an interoperable function cannot meet its contractual obligations, the introduced change is substantive.

Because V3 has more artifacts and is more explicit, there is more probability that ANY introduced change will be substantive, unless it was just a change to definition to improve clarity.  The following are examples of substantive changes:

    • Changing constraints on data.
    • Changing the properties of an existing data type - For example, Add a property to AD to indicate the parts are unordered.
    • Changing the value set assigned to a structural table - For example, Use of an HL7 defined vocabulary instead of xml:lang for coding languages.  This is non-controversial, but substantive.
    • Changing definitions that change receiving system behavior.


V3 Non-Substantive Changes description can be found by clicking below.


V3 Non-Substantive Changes

Changes to descriptive text that clarify, but do not change meaning, are considered non-substantive:

    • Typographical corrections.
    • Formatting corrections.
    • Changes made to graphics.


V3 Elements and Substantive Change

This section lists elements of a Version 3 Standard with rules and examples of substantive and non-substantive changes. See the Version 3 Guide in the HL7 Ballot document for more information on each element. As a general rule, changes that are made to non-normative elements are not substantive. Changes to normative elements may be substantive.

Storyboards

A storyboard consists of a short description of its purpose and an interaction diagram that shows the progression of interactions between application roles. A storyboard narrative is a description of a real-life event that provides the necessary context for the development of a specific interaction described in the storyboard. The process of storyboarding lays the foundation for describing HL7 messages and their content. Storyboards are not normative. Therefore, changes to Storyboards are not substantive.

Application Roles

Application Roles represent a set of communication responsibilities that might be implemented by an application. They describe system components or sub-components that send or receive interactions.  Application Roles are not normative. Therefore, changes to Application Roles are not substantive.

Trigger Events

A Trigger Event is an explicit set of conditions that initiate the transfer of information between system components (application roles).  Trigger Events are normative. Changes to normative elements may be substantive.

Here are some examples:

    • Adding or deleting a Trigger Event is a substantive change.
    • Changing descriptive text that alters Trigger Event rules is a substantive change.

Domain Message Information Models

The Domain Message Information Model (D-MIM) is a subset of the Reference Information Model (RIM) that includes a fully expanded set of class clones, attributes and relationships that are used to create messages for a particular domain. D-MIMs are not Normative. Therefore, changes to D-MIMs are not substantive. However, a change to an R-MIM not supported in the D-MIM is Substantive, because messages will fail.

Definitions

Backwards Compatibility: A change that would create a backward compatibility problem is a substantive change. For backwards compatibility, a message recipient is expected to process a new message and ignore added material. If there is new material that needs to be parsed in order to process the message given its new definition, the change is substantive.

Some general rules for a Backwards Compatibility are:

    • From the V3 perspective, the focus is on message types.  As long as there is a set of message types that do what was done before, the contents of a ballot are backwards compatible.
    • Neither attributes nor associations can be removed from a message type.
    • Association cardinality cannot be tightened.
    • You can change attribute conformance from Mandatory to Required, and from Required to Optional, but not the reverse.
    • You cannot remove values from the HL7 defined value sets for structural codes.  This includes all attributes with CS data types.
    • If a particular coding system is associated with a domain within the ballot, it may not be removed.
    • If a particular value set is associated with a domain within a ballot, the value set reference may not be removed, nor may any code be removed from the value set.
    • No interaction may be removed that existed in the prior ballot.  This precludes removal or redefinition of a trigger event.
    • Receiver responsibilities may not be removed from interactions.

Non-substantive: A change is considered to be non-substantive if it would not cause an interface to fail when a message was sent or received. All technical corrections are non-substantive changes. Changes made to non-Normative material are not substantive.

Substantive: Substantive changes modify the standard by adding or removing capabilities. A change is considered to be substantive if it would cause an interface to fail when a message was sent or received.  This is similar to, but more expansive than, the definition of backwards compatibility.  A change that creates a backwards compatibility problem is substantive by definition.

FHIR Substantive Changes description can be found by clicking below.


FHIR Substantive Changes

    • New resources and data types.
    • Cardinality changes.

FHIR Non-Substantive Changes description can be found by clicking below.


FHIR Non-Substantive Changes

    • Section renumbering.
    • Correcting broken links.
    • Changing styles
    • Correcting typographical errors.
    • Providing clarifications that do not change the meaning of the specifications.
    • Corrections that are judged not to create any expectation of a change to a conformant applications.
    • Changes to examples.

Technical Corrections

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

Managing Substantive Change

The TSC will play the following role in the management of substantive change:

    • Define the criteria for substantive changes.
    • Review, upon request, proposed changes to determine whether they are substantive.
    • Act, as a general matter, in the role of an auditor.  It is important to recognize that the TSC may need to discuss changes with the WG, because the application of the rules needs to consider the context.

Submitting ANSI-approved HL7 Standards for ISO Approval

Once an HL7 standard is ANSI-approved or is published as a Standard for Trial Use (STU), it can be submitted for approval by the International Organization for Standardization (ISO) under a special agreement.  Please review  information and complete instructions  to follow this process.




Chapter 6 Working Group Meeting Planning

Responsibilities at the WGM

Co-chairs are expected to attend all WGMs.  Obviously, there will be occasions when you cannot, for work or personal reasons, attend.  But generally you should plan on attending all WGMs.  Arrive in time to meet all of your commitments as co-chair of your WG and to check over your meeting room.  This will certainly include attending the co-chairs’ meeting on Monday evening which is a WG Health Metric. Announce your agenda at your meeting. It is good practice to do introductions each quarter at the WGM. This helps new attendees become familiar with your work group and its members/participants and allows new attendees to be introduced to the larger group. Before adjourning your session at the WGM, work with your group to define a preliminary agenda for the next WGM or conference call; preferably no later than Wednesday of the current WGM.

Key Documents for this chapter

Agenda icons for Work Group Meetings

Governance and Operations Manual (§08.03 Majority Rule, §05.01 Antitrust Policy)

Work Group Health

Work Group Meeting Checklist 

Work Group Meeting Room Request form


Action Items

Schedule rooms for next WGM 1 week post WGM

WGM Agendas to be posted 4 weeks prior to meeting

WGM Meeting Minutes to be posted +2 weeks post WGM

 

Work Group Health Metrics

There is an ongoing effort to ensure that WGs are open, active and effective. The measures of perceived WG health include a few simple items identified to better align the WGs with HL7 expectations for effective WGs.  WG Health Metrics are produced before each WGM.  The following TSC Confluence page includes the details on what is measured in the WG Health Metrics as well as approval requirements for the Work Group Mission and Charter Statement (M&C), Decision Making Practices (DMP), and Strength/Weakness/Opportunity/Threat (SWOT) analysis.

Co-Chair Dinner - Monday night of the Working Group Meeting

The co-chairs dinner/meeting is composed of the co-chairs of all WGs and committees within HL7, HL7 leadership and staff.  Additionally, any WGM attendees are allowed to observe but not actively participate in discussion or decision making unless they have been invited to participate on specific topics.  While registering for the WGM, co-chairs should indicate their intent to attend this meeting.  It is typically scheduled for Monday evening during each WGM.  Check the meeting brochure to confirm the date/time and location of this meeting.  While all co-chairs are encouraged to attend the meeting, only one co-chair per WG is required to attend.  Each WG will designate one co-chair from among the co-chairs to represent their interests at the co-chairs dinner/meeting.  They are the official spokesperson and voting co-chair for their WG.

Keep Attendees Apprised of Agenda Changes

Occasionally, WGs need to change their agendas or cancel or add meetings.  To ensure that all WGM attendees are kept up to date on these types of changes, co-chairs are required to make announcements regarding these types of changes in a timeframe that aligns with the group's DMP. To ensure that these types of changes are communicated to all attendees, co-chairs are required to post these announcements to their WG listserv, and on the bulletin board near the WGM registration desk.  Additionally, co-chairs may also wish to make these announcements via the HL7 mobile app.  Since all attendees do not use the mobile app, making these types of announcements only via the mobile app is not appropriate.

Preparing for the WGM

Appoint an Acting Co-chair as Needed

Infrequently, there may be occasions when no co-chairs from your WG will be available to attend a WGM.  For these occasions, WGs may appoint an acting co-chair by bringing a formal motion to the WG in advance of the WGM.  GOM §08.03 Majority Rule allows for any formal motion (including one to appoint an acting co-chair(s)), to be brought for vote to the WG using its DMP. 

Acting co-chairs shall have all the powers, privileges, and responsibilities of an elected co-chair for a specific period of time with no expectation of election.  An acting co-chair would typically be appointed to preside over the WG sessions at a WGM.  The co-chair powers, duties and responsibilities revert back to the elected co-chairs at the conclusion of the WGM.

Select an Interim Co-chair

HL7 has a formal process for electing co-chairs, which include a 30-day call for nominations and elections at the WGM.  Occasionally, a co-chair will resign at a point in time that occurs after the 30-day call for nominations.  When this occurs, WGs may select an interim co-chair by a vote of hands during their WG meeting.  The interim co-chair will serve until such time as a formal election can be announced and held.   Unlike an acting chair, an interim chair has all the powers, privileges and responsibilities until the formal election is held.  Many times, the interim chair anticipates being elected during the formal election period. Interim co-chairs will be added to the appropriate list servers and web pages.

Ensure that Meeting Minutes are Taken

If you have a WG secretary or a co-chair who is responsible for taking minutes, verify that he or she will be in attendance.  Otherwise, ask for a volunteer to provide notes or minutes in electronic form so you can focus on chairing the meeting. 

Minutes can vary widely in their depth of coverage.  WGs must use Confluence for recording their minutes.  There is an agenda/meeting notes templates available for use. 

To create a teleconference agenda/meeting notes page in Confluence, go to the page you want to create the agenda or meeting notes under.  Click the "three dots" beside the "Create" button on the blue bar. 

Click "Show More" and scroll to find the "Teleconference Agenda/Meeting Notes" Template. 

The minutes should include:

  1. A list of attendees
  2. Antitrust Statement: Professional Associations that bring together competing entities, such as HL7, are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 activities, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust policy as stated in §05.01 of the Governance and Operations Manual (GOM).
  3. Precisely worded motions that were made along with indication of how successful they were (passed unanimously, passed without objection, or the actual number of votes for, against, and abstentions).  Motions and tallies related to ballot reconciliation can, instead, be recorded in Jira Specifcation Feedback Project, and posted as noted under item 5 below.
  4. Descriptions of any associated work products (white papers, draft documents, presentations, etc.).
  5. The agenda for the next meeting
  6. Electronic copies of all work products of the WG including papers that were presented at the meetings, overheads, etc. Text files, Microsoft Word documents and PowerPoint documents are the three most common ways of providing information. Combine the minutes and all related documents in a single .ZIP archive and upload it to the website.

If your WG did not achieve quorum, post a document stating that fact and that no business was conducted.  While there can be no binding decisions on calls that do not achieve quorum, minutes of the discussions, should there be any, should be taken and posted to the website.

Your WGM meeting minutes are expected to be posted within two weeks following the WGM. Conference call minutes should be posted as defined in the Decision Making Practices document. 

The posting of minutes is a WG Health Metric.

At the Work Group Meeting

Meeting Room and AV Requirements

Instructions for requesting meeting rooms for the next WGM are distributed at the co-chairs’ dinner meeting held on Monday evening of the current WGM.  Co-chairs will also receive a reminder email from the Director of Meetings with instructions and the URL for room scheduling for the next WGM.

Rooms are assigned in the following priority, based on room size and availability:

1)      Work Groups

2)      Board-appointed Committees

3)      HL7 Special Projects Groups

4)      Ancillary Groups

Request only the space you will need and indicate the numbers of attendees you expect at the WG meeting.  In the event more participants attend than were planned for, the HL7 Director of Meetings can have additional chairs brought in.

Meeting space for the next WGM is requested online. Room requests for all joint WGMs planned for the next WGM, must be submitted to the HL7 Director of Meetings no later than the Friday following the WGM as specified in the section below.

WGM Room Requests

Meeting room requests for the next WGM are submitted online no later than Friday of the week following the most recent WGM, (7 calendar days). You must include your AV requirements in the online form.

Requests for meeting rooms for joint WG meetings are made after the co-chairs of the WGs determine a day and quarter(s) which they would like to meet.  The co-chairs determine which WG will be designated as the Host. One of the co-chairs of the Host WG will submit the meeting room request for the joint meeting when they submit the meeting room request for the next WGM.  The non-Host WG(s)  WILL NOT  request meeting room for the quarters when they are meeting jointly and should not include any reference to it in their WGM request.

For assistance using the WGM Room Request Application, please take the opportunity to view a short webinar targeted to co-chairs demonstrating the use of the application to request conference rooms for upcoming WGM.

AV Requests

When requesting AV support, consider your needs carefully and request only the items needed.  The following items should be considered: LCD projector; screen; power requirements (strips); and sound system for large groups and special presentations.

Photocopy Requests

HL7, like many organizations, is “green” and therefore encourages the use of electronic rather than hardcopy documents. If you need photocopies during the WGM you will need to obtain them through the meeting venue business support office or contract for photocopy services with an off-site provider.

Meeting Change Notification

Notify the WGM registration desk of any changes to your scheduled WG sessions.  The headquarters staff posts changes to scheduled WG sessions to a bulletin board near the registration desk and can ensure the change is posted to HL7 mobile app.  This alerts interested attendees of the changes and advises the staff of changes. You may also need to announce meeting changes on your WG’s list server or via other means as defined in your WG’s DMP.

Prepare a Detail Meeting Agenda

WGs should plan the agenda for the following WGM by Wednesday of the current WGM in order to determine room requirements and joint meetings for the following WGM.  Agendas for upcoming WGM are to be posted as soon as possible to the WGM Confluence page for the appropriate meeting so that WGM attendees can plan their participation well in advance of the meeting.

HQ will send several emails to co-chairs reminding them to post their agendas.  Agendas can be updated as needed and reposted to the Confluence space.  Once an agenda is set you should consult with your WG prior to changing the agenda, particularly for items that might impact travel schedules.  For example, some organizations have different representatives for work on different specifications and/or product families, so changing those agenda items could adversely impact travel plans.

If the agenda is changed after the WGM has started, post those changes on the bulletin board near the WGM registration desk and announce the change on the WG list service. Additionally, co-chairs may also wish to make these announcements via the HL7 mobile app.  Since all attendees do not use the mobile app, making these types of announcements only via the mobile app is not appropriate. 

Agendas should be brief but cover the major topics including, but not limited to, votes or elections that may be coming up.  The Plenary meeting (usually in September) has a general session Monday morning (Q1, Q2) with the WG sessions beginning after lunch (Q3.). Plan your agenda accordingly.  An agenda template is provided on the website along with agenda icons.

Responsibilities after the WGM

Submit Meeting Room Requests for the Next WGM

Within one week following the end of the most recent WGM you must submit your request for your regular meeting room for the next WGM via the  web form  announced at the TSC meeting during the most recent WGM.

WGM Posted within 2 weeks

Submit minutes and associated work products within two (2) weeks following the end of the most recent WGM. Get the minutes from your secretary or the person who took notes for you.  Review, edit and have the WG vote to approve them. Note that minutes may be approved by “general consent” when there are no corrections; the co-chair states “You have received the minutes. Are there any corrections to the minutes? Hearing none, if there are no objections the minutes are approved as posted.”  Once approved, upload them directly to the web site by going to the Minutes repository for the individual WG located on the WG page.  You can upload you minutes in Word, PDF or Zip file format.  You are encouraged to include machine-readable diagrams in your minutes. Should you choose to post meeting minutes to the WG Confluence Space, a link to the location must be included in the “Minutes” tab of the WG’s web page.

Communicate with your WG members via teleconference or by e-mail; monitor and facilitate any work towards deliverables that are due before or at the next WGM.

Submit Post WGM Survey

One of the co-chairs of each WG must complete and submit the post-WGM co-chair survey providing feedback on the WGM. This survey will be available the week of the WGM. Many WGs complete the survey as they are concluding their WGM sessions. Several emails will be distributed to the co-chairs listserv reminding co-chairs of the survey, its location, and date by which responses are due. Completion of this survey is a WG Health Metric; WGs are encouraged to complete the survey on time.


Responsibilities between WGMs

WG Co-chairs should attend the Co-Chair Webinar that are typically held on a monthly basis between WGMs.  If you are unable to attend, the recording of the Webinar is available on the Education on Demand portal.  



Chapter 7 - Work Group Health

There is an ongoing effort to ensure that WGs are open, active and effective. The measures of perceived WG health include a few simple items identified to better align the WGs with HL7 expectations for effective WGs.  WG Health Metrics are produced before each WGM.  The following TSC Confluence page includes the details on what is measured in the  WG Health Metrics  as well as approval requirements for:

    • Work Group Mission and Charter Statement (M&C),
    • Decision Making Practices (DMP), and
    • Strength/Weakness/Opportunity/Threat (SWOT) analysis.

Work Group  mission and charter statement  must be reviewed periodically, at least every five years as reflected in WG Health Metrics, with or without updates made. During this review, the WG M&C should also be compared to the current  M&C template  to maintain consistency with the current format.

Updated M & C are sent to the TSC for review and approval. If no updates are made, please indicate to the TSC Project Manager that the M & C was reviewed and no changes made. The review date can then be updated on the WG's web site.  Approved updated M&C should be forwarded to the TSC Project Manager for posting to the WG web site.

Decision Making Practices (DMP) are written from the point of view of a group with an open membership and reviewed every 3 years. Most sections of the default DMP apply to all groups and are not modifiable. Sections that can be modified via the HL7 DMP Addendum are:

    • 5 - Quorum Requirements
    • 7 – Electronic Voting (particularly items c, d and e)

Strength/Weakness/Opportunity/Threat Analysis is to be reviewed every 5 years.

Key Documents for this chapter

Mission and Charter template 

WG Health Metrics


Action Items

Decision Making Practices - Reviewed every 3 years

Mission Charter - Reviewed every 5 years

Strength/Weakness/Opportunity/Threat Analysis - reviewed every 5 years

This page contains the links and charts for the latest Work Group Health (WGH)  and PBS Metrics information.

There are several aspects to Work Group Health besides key functional documents outlined above and can be viewed in the Work Group Health Table.

For those WGs that maintain green for the period between WGMs are awarded Gold Stars for all of their members. For WGs that maintain Gold Stars for all period in a year are awarded a trophy that is displayed on their WG web page. This is certainly the benefit of keep all aspects of WG Health up to date, however, the real value is the ability of our membership to learn timely what is happening at HL7 so that they can get involved where they see the most benefit for themselves and the companies they represent.



  • No labels