Revised HL7 Technical Steering Committee

From HL7 TSC
Jump to navigation Jump to search

- It's Mission, Responsibilities, Composition and Formation

Contents

Introduction

This document provides specific recommendations from the Technical Transition Task Force (T3F) to the HL7 Board. It includes a complete definition of a restructured Technical Steering Committee (TSC), its composition and relationships, and proposes a plan to elect and establish the revised Technical Steering Committee to allow its first meeting at the September 2007 Working Group Meeting in Atlanta.

Background

The T3F began work in earnest at the Winter Working Group Meeting in January 2007. The T3F met three times face-to-face at that meeting and has held a conference call every week but one since then. The group used a number of sources in its efforts -- Strategic Initiative documents, ORC reports, work from the project life-cycle team, etc. In addition, the group has benefited greatly by having consistent attendance at its meetings from the TSC (Quinn and Hammond), the ARB (Walker) and the project life-cycle group (McCaslin), and wishes to thank each of these groups for their support.

Early on in its efforts, the T3F determined that its primary initial task was to provide a complete definition of the roles and composition of a revised Technical Steering Committee that could be adopted at the May Working Group Meeting. This would afford the opportunity to review these recommendations in Cologne and allow the Technical Steering Committee to be reformed as rapidly as possible thereafter.

Designation of "TSC"

Some readers will be aware that while the T3F was drafting these recommendations it thought that the group being formed would be called the HL7 Technical Directorate. As this proposal was reviewed at the Board, it became clear that the term Technical Directorate will include both this body, HL7 staff and officers such as the CEO and CTO. Therefore, the decision was taken to retain the traditional "Technical Steering Committee" title, and express these recommendations as a revision or restructuring of the TSC functions.

In this context, "Technical Steering Committee" will refer to the elected and appointed representatives of a ten-member committee that will oversee the technical affairs of HL7 and is the primary focus of this document. This group will continue to convene Technical Steering Committee Plenary Meetings of the Co-chairs of all HL7 Technical Committees and SIGs at each WGM.

Status of this Document

The T3F regards this document as a draft of a "contract" between the Technical Steering Committee and the HL7 Board of Directors. It should be a "living" document that evolves as the TSC evolves. It should not be replaced by a "Charter" for the Technical Steering Committee, but rather the Charter should be drawn from this document and evolve as this document and the TSC itself evolves.

More specifically, the T3F recommends that the TSC adopt a "Sunset" Review" of this document to commence after the new TSC has been functioning for two years. At that time, all of the recommendations for TSC structure and function should be formally reviewed. The TSC should then make a report to the Board assessing what is working, what is not and include proposed changes, if any are needed

The original version of this document was released April 28, 2007 for review at the HL7 Spring WGM in Cologne. The current release was prepared May 22, 2007, and reflects changes (mostly modest) made by the T3F during subsequent meetings and conference calls.

Mission

Mission Statement

The HL7 Technical Steering Committee oversees and coordinates the technical effort contributed by the HL7 volunteers who make up the HL7 Working Group. Its mission is to assure that the efforts of the Working Group are focused on the overall HL7 mission established by the HL7 Board.

The Technical Steering Committee and the HL7 Working Group operate in such a way so as to:

  • respect the contributions and ideas of the talented individuals who make up the Working Group;
  • maintain an effective focus on the goals of HL7;
  • assure that the all major decisions are based on consensus of the stakeholders;
  • maximize sharing and "re-use" of work products between elements of the Working Group;
  • use project management to assure that project goals are articulated and met;
  • reduce competition and conflict between the elements of the Working Group; and
  • assure that HL7 standards are developed on a solid architectural foundation that assures consistency and interoperability.


Success Criteria

The Technical Steering Committee success criteria must focus on three core objectives -- assuring the continuity and vitality of the HL7 volunteer-based Working Group; maintaining coherent inter-operable standards while minimizing duplication of effort; and providing sound consensus-based standards that meet the needs and schedule requirements of HL7's clients.

The Technical Steering Committee will be successful if HL7 members can easily find answers to the following sorts of questions:

  • What is HL7 doing in the area of xxx? Where xxx is an area of interest to a member
    • what publications exist?
    • what active projects / work-items are there?
    • what committee is responsible for that area?
  • What is happening on this project?
    • When will it deliver?
    • What can I do to make that faster / more likely to deliver on time?
    • What has happened recently (is it really active?, has it delivered on schedule?) What is happening to this publication?
  • How do I know what to do at a WGM?
  • What is the status of a particular HL7 specification or document?
    • Who is using / plans to use this publication?
    • What feedback was received to this DSTU?
    • What change proposals are open for this publication?
    • Who maintains this document, and where do I send comments / questions
    • What is the ballot history for this document (when was it balloted, and what were the comments and resolution, and what was the ballot pool)
    • Are there any plans to produce a revision for this document?

Defining success criteria in this way shows how the TSC is mandated to expose the information that is needed for the board and membership to be able to plan effectively and to support the promotion of the consensus-based products. It also underpins the importance of work reuse, and only having as many projects and committees as are needed. Finally it defines success in a way that reflects the questions that led to the recommendations to restructure the TSC.

Responsibilities

This section is based on Strategic Initiative documents, on-going revision by the T3F, the Mission statement above, and consideration of the stated responsibilities of the Technical Steering Committee as documented in HL7's Bylaws and the Policies and Procedures Manual. These responsibilities are shared, as noted below, with the four Steering Divisions (SD) (sub-groups of committees) that report to the Technical Steering Committee.

Oversees Execution of Standards Development

Assures that the efforts of the Working Group (WG) are effectively focused on accomplishing the product and services strategy set forth by the Board.
  • Participates in development of an HL7 Product and Services strategy for adoption by the HL7 Board
  • Oversees the TSC Steering Divisions (SD) in the establishment and management of projects and project teams to accomplish the product and services strategy set by the Board. To that end, it works through the SDs to:
    • Approve new work groups based on priority projects
    • Dissolve work groups no longer required based on the HL7 Products and Services strategy
    • Works with sub-groups to align and prioritize projects in accordance with the products and services strategy
    • Working with the subgroups, helps to ensure the availability of project resources
      • helps with resource provision or recruitment (people, rooms, tools, etc)
      • includes ensuring the continuity, vitality, and effectiveness of the HL7 volunteer-based Working Group
  • Approve, monitor, and perhaps intervene in overall product development
    • Works with the SDs and the PMO to oversee the tracking of projects to meet HL7 objectives. The Steering Divisions will function to assure that they or the committees under them set milestones, monitor and ensure that quality assurance has been done
  • Performs top-level review and authorizations as specified in the formal development process:
    • Working with the SDs, reviews, approves, and prioritizes requests for new projects.
    • Working with the SDs, recommends project probation or dissolution to the Board
    • Sets remit for ARB and Project Management Office and serves as escalation point for issues not resolved at the committee or SD level.
    • ensures that quality checks in the project development process are satisfied.
    • Reviews and approves requests from Technical Committees to initiate a ballot and serves as escalation point for ballot response handling.

Provides a Coherent Architecture and Development Process

Establishes (or reviews) the Technical Architecture, the development methodologies, and the work processes to be used by the WG in developing HL7 consensus-based standards specifications
  • has overall responsibility for the development and adherence to an HL7 Technical Architecture and the development, maintenance, and execution of an HL7 standards development process
    • working through SDs, makes sure that architecture and process is developed, communicated (documented, etc), maintained and enhanced.
      • through Committees such as MnM, Vocabulary, and PIC as well as the ARB.
  • defines and manages international harmonization mechanism
  • ensures that the balloting of any HL7 specification, or portion thereof, is carried out in accordance with HL7 Bylaws and ANSI rules.
  • holds ultimate responsibility for harmonization of committee work products. Harmonization is the process whereby the various shared models of the HL7 Technical Architecture, are defined for common use by the HL7 Working Group and for use between collaborating SDOs. The harmonization process must consider the requirements of the HL7 architecture, the need for sharing and re-use, and the requirements of the various domains of use. The tasks of the Technical Steering Committee will include:
    • to define the principles under which harmonization activities should operate;
    • to lay out the general processes to be followed;
    • to assign responsibility for the carrying out each harmonization area to a specific committee or project within the Working Group; and
    • to monitor and act as the focus for appeals to the process.

Oversees the Technical Operations of the Working Group

Assures that the WG works smoothly together and covers the work scope in a consistent manner.
  • Ensures that Working Group policies and procedures and bylaws are followed
    • With the SDs, oversees execution of procedures for committee creation, dissolution, and co-chair elections.
    • ensures that meetings and calls are carried out according to policy
  • Oversees continuous quality process
  • Works through SDs to identify cross-domain and cross-function gaps, overlaps, discrepancies, potentials for collaboration, and conflicts and recommends resolution
  • responsible for any official interpretation of the HL7 standards.
    • resolves conflicts within the Working Group and prioritizes resources according to project priority (example, room balancing at WGMs)
    • ensures the impartial handling of substantive and procedural

complaints regarding any action or inaction as related to the production of HL7 specifications.

Primary Communication Vehicle for the Technical Operations of HL7

Serves as technical authority of HL7, communicating status and guidelines regarding standards and operations.
  • serves as technical escalation point for any questions related to the technical operations of HL7
  • reports to the Board, the WGM, and the membership on Technical operations news, status, and issues as appropriate
  • responsible for any official interpretation of the HL7 standards.

Composition

The T3F spent several meetings deliberating the appropriate composition and style of functioning for the Technical Steering Committee. This section reflects the results of those discussions, and addresses three topics:

The order of these topics is arbitrary and the discussion will, of needs, include both forward and backward references. The T3F did not attack any of these topics de novo. In every circumstance, we built on the guidance provided by earlier Strategic Initiative, ORC and Transition documents. We sought to recognize the principles and objectives that underlay each of those documents and to maintain those principles and objectives while improving, we hope, the resulting framework.

HL7 Committee Structure

The HL7 Working Group is made up of a number of volunteer-driven Committees and SIGs that have been highly successful, to both their own and to HL7's credit and benefit. Simultaneously, however, as the numbers of groups expanded, their breadth, number and diversity posed major challenges for coordination and collaboration between them. Discussion and debate on such issues in the forum of the previous Technical Steering Committee (TSC) became difficult and unproductive in recent years, and failures in coordination have begun to threaten the effectiveness of HL7.

The challenge of the Strategic Initiative was to address these coordination and collaboration issues while retaining the essential vitality of a Working Group made up of and driven by the best, brightest and most dedicated medical informaticists and information scientists available. The essence of the Strategic Initiative proposal was to revise the leadership of the Working Group from a single TSC with representation from each Committee and SIG to a two-level hierarchy of a Technical Steering Committee (TSC) and a small set of Steering Divisions (SD, a new term). This was the foundation from which the T3F developed this proposal.

The starting point for this discussion was a previously developed Strategic Initiative document titled "Creation of the Transitional Technical Task Force (T3F)". The final proposal can be summarized with the "nested list" of bullet points at the end of this paragraph. The remainder of the topics in this "HL7 Committee Structure" section discuss the rationale and principles behind this proposal, specific responsibilities of the TSC and SDs, and the definition and committees in each Steering Division. The proposed hierarchy is:

  • Technical Steering Committee -
    6 elected voting representatives, 4 appointed voting members
    TSC-elected Chair
    • Foundation & Technologies Steering Division
      9 existing TCs and SIGs
      2 Elected SD Co-Chairs plus Co-Chairs of TCs & SIGs in SD
    • Structure & Semantic Design Steering Division
      10 existing TCs & SIGs
      2 Elected SD Co-Chairs plus Co-Chairs of TCs & SIGs in SD
    • Domain Experts Steering Division
      17 existing TCs and SIGs
      2 Elected SD Co-Chairs plus Co-Chairs of TCs & SIGs in SD
    • Technical & Support Services Steering Division
      9 TSC-appointed Committees (7 formerly Board-appointed, 2 new)
      2 Elected SD Co-Chairs plus Co-Chairs of Committees in SD

Organizing Principle

During its deliberations, the T3F made the following observations:

  • HL7 members join committees because of their personal (or corporate) interest in the subject matter content of the committee, regardless of whether their interest stems from academic, development or implementation activities.
  • The original break-out of committees (provided in the SI document) aggregates the committees by commonality of what they produce and the relationship of that work product to the other Working Group committees. The T3F found this is to be a sound approach.
  • One of the key activities of the TSC will be to identify and reduce those places where committees are "stepping on each others toes" or "reinventing the wheel." Coordination within the proposed Steering Divisions will facilitate this activity.
  • The existing relationship between TCs and SIGs may need to be "re-thought", because the Steering Division strategy will clearly place a number of SIGS in a Steering Division that is different from that to which their current "parent TC" is assigned.
  • It will be important to not disrupt existing collaboration while establishing this organization, and it is clear that many topics may best be managed, in "matrix fashion" between committees in two or three Steering Divisions.
  • A number of committees clearly produce products that fit in two or even three of the Steering Divisions. This may be effective, or it lead the TSC to consider whether to recommend these groups be split.

Ultimately, the T3F recognized that the organization as proposed is imperfect, not by design, but by the nature of the HL7 Committees and SIGs that do not permit simplistic classifications. Regardless of what is proposed, someone will question the result. The key element however is to establish the three-tier structure first, gain the advantages of focusing critical organizational thinking into smaller meetings so that the work can get done, and then evolve the structure over time.

Technical Steering Committee Role

The Technical Steering Committee (TSC) will be the focal point for decision making, harmonization, issue resolution, project and committee creation and dissolution within the Working Group. The TSC will be a representative consensus body of elected and appointed members. (Specifics are in a later section of this document.)

The T3F notes that however the Steering Divisions are defined, and whatever additional relationships may exist between committees, the Technical Steering Committee will not be successful in meeting HL7's objectives unless it can assure the harmonization of content and design across HL7 standards.

As a consequence, the notion of required harmonization and shared stewardship must clearly be a fundamental principle of the TSC, of the Steering Divisions, and of each TC and SIG. Overall, it is the TSC that must define and manage the processes that bring about such harmonization and then must delegate similar responsibilities to the Steering Divisions and to the committees.

Further, the TSC must have a central role in project management. It is assumed that the project life cycle strategy being developed will be a fundamental process for all HL7 work. The TSC will incur responsibilities:

  • to approve projects (after they are vetted in the Steering Divisions)
  • to initiate projects to carry out its mission (such as harmonization)
  • to oversee the functions of the Project Management Office, and
  • to maintain the project life cycle definition

Certainly, several of these responsibilities will need to be delegated in whole or in part to the Steering Divisions or to specific committees.

Steering Division Definition and Composition

In keeping with the original Strategic Initiative document, T3F proposes to divide the existing Technical Committees, Special Interest Groups and Board-appointed Committees into four functional groups called Steering Divisions (SD). Each Steering Division will be a committee in its own right made up of the Co-Chairs of the groups in the SD. It is expected that each SD will meet face-to-face during each Working Group Meeting and will conduct conference calls, as needed. A partial list of specific SD responsibilities includes:

  • nominate and elect the representative from that SD to the TSC, who will also serve as a Co-Chair of the SD
  • nominate and elect an Alternate representative to the TSC, who will also serve as a Co-Chair of the SD
  • review proposed projects and make recommendations for action to the TSC
  • monitor project status within the SD
  • review proposals to create, modify or dissolve Committees and SIGs in their SD and make recommendations for action on same to the TSC
  • identify coordination issues within and between the committees of the SD and resolve these or recommend resolutions to the TSC
  • identify coordination issues between SDs and their committees and recommend resolutions to the TSC
  • undertake harmonization tasks as delegated by the TSC
Foundation & Technologies Steering Division

Committees and projects in this space focus on providing the fundamental tools and building blocks that other Committees should use to build the standards, and upon the technology infrastructure that implementers of HL7 standards must manage.

  • Conformance
  • Infrastructure & Messaging
  • Implementable Technology Specifications (ITS)
  • Java
  • Modeling & Methodology
  • Security
  • Service Oriented Architecture (SOA)
  • Templates
  • Vocabulary
  • Related multi-committee projects:
    • Dynamic Model
    • Harmonization
    • HL7 TermInfo
Structure & Semantic Design Steering Division

Committees and project in this space focus on creation of basic patterns and common messages that could exist on their own, but are mostly used by others.

  • Clinical Context Object Workgroup (CCOW)
  • Clinical Decision Support
  • Electronic Health Record (EHR)
  • Financial Management
  • Genomics
  • Orders & Observations
  • Patient Administration
  • Personnel Management
  • Scheduling & Logistics
  • Structured Documents
  • Related multi-committee projects:
    • Clinical Statements
    • Common Message Element Types (CMETs)
Domain Experts Steering Division

Committees and projects in this space focus on creation of messages, services, documents using many of the common structures in place, yet expanding it in key areas as well.

  • Anatomic Pathology
  • Anesthesiology
  • Attachments
  • Cardiology
  • Clinical Guidelines
  • Community Based Health Services
  • Emergency Care
  • Government Projects
  • Health Care Devices
  • Imaging Integration
  • Laboratory
  • Patient Care
  • Patient Safety
  • Pediatrics Data Standards
  • Public Health Emergency Response (PHER)
  • Pharmacy
  • Regulated Clinical Research Information Management (RCRIM)
Technical & Support Services Steering Division

These committees are currently Board-appointed. In future, the T3F recommends that they be appointed by the TSC, subject to Board approval. The committees will elect their own Co-chairs, subject to TSC approval. For the most part, these groups are functioning on efforts of volunteers who accepted a board request (past) or will accept a TSC request (future) to take on these responsibilities in collaboration with the designated staff liaison. Because these groups were not members of the previous TSC, they had no voice in TSC decisions, even though they were working alongside the volunteers in the other groups. Thus, the addition of these committees to a Steering Division provides those volunteers equal voice (and responsibilities) in the TSC affairs.

The primary feature of these committees is that their projects and products provide direct support to the Technical Committees and SIGs of the Working Group and thereby enable the Working Group to function efficiently.

  • Education
  • Electronic Services
  • Implementation
  • Marketing Committee
  • Process Improvement Committee (PIC)
  • Project Services -- a new group that will take responsibility for the Project Life Cycle and will serve as the primary support for the PMO
  • Publishing
  • Tooling
Architecture Review Board

The T3F believes the Architecture Review Board (ARB) fulfills a critical mission that must continue under the TSC. To that end, the T3F is proposing that the ARB become a TSC-appointed committee that "stands alone" (independent of the Steering Divisions), and (see below) that the ARB have a voting representative on the TSC. Normally this representative will be the ARB Chair, but in the circumstance that the ARB Chair is already a member of the TSC, a different ARB member will also be named to the TSC.

Maintaining Open Communication with TSC Constituent Committees

The structure of the TSC threatens to isolate the Technical Committee and SIG leadership to discussions in only a single Steering Division, whereas, under the previous TSC, communication and collaboration occurs across a variety of committees with no established barriers. In order to avoid such isolation, the Technical Steering Committee should establish procedures such that:

  • even though the Steering Divisions have the first-level responsibility for coordinating the activities within their divisions, all proposals for new or changed Projects and all proposals for new or changed committee status should be shared with the members of all Steering Divisions as soon as the proposal is released for review by any SD. This will allow cross-SD comment and the opportunity to seek modifications in proposals before they have been formally adopted at an SD.
  • at each WGM, the TSC should hold a Technical Steering Committee Plenary Meeting of all of the Co-chairs. This session should be chaired by the TSC Chair. In addition to "TSC Retreat" style presentations the plenary should include an "open mic" period during which individual Co-chairs can present concerns and issues. The plenary would hear a brief presentation of the issues, and accept a written form of the issue (similar to a ballot comment). The TSC should then have the obligation to acknowledge all issues, assign them to an SD or other group for response/action, and assure that the issue is indeed addressed or responded to by the assigned group.

Composition and Functioning of TSC

The makeup of the proposed Technical Steering Committee is illustrated in the following chart. It includes ten voting members -- six elected representatives, two Board-appointed positions (the CTO and a liaison), and up to two TSC-appointed positions. It also has a non-voting secretary, to be assigned by HQ, and other staff support positions. Specifics of the election processes, terms, etc. are in following sub-sections. [Note: This graphic has not been updated. Please, mentally, substitute "TSC" for "TD" every place it appears.]

TDComp-v3.png

[Note: This graphic has not been updated. Please, mentally, substitute "TSC" for "TD" every place it appears.]

TSC Membership

Steering Division Representatives

Each of the four Steering Divisions (SD) will have an elected voting Representative on the TSC. Further, each SD will elect an Alternate Representative who is authorized to attend TSC meetings and vote in the event the elected Representative from that SD is unable to participate. This assures strong, consistent representation from each SD. In addition, the primary and alternate representatives will serve as Co-Chairs of the Steering Division itself.

The election process for SD Representatives is patterned after the process used in 2006 to elect the T3F representatives:

  1. During a nomination period of at least 30 days, nominations for representatives of the SD will be accepted from the Co-Chairs of the Committees and SIGs that make up the SD.
  2. The nominees are expected to be individuals who are either current Co-Chairs or a past Co-Chair of one of the Committees or SIGs in the SD. Effective service on the TSC will require such experience. Nominees should be prepared to commit at least two hours a week to the TSC, if elected.
  3. HL7 staff will contact nominees to verify their willingness to stand for election, and to solicit a brief nominees "statement" for distribution.
  4. Individuals who are nominated to represent more than one SD will be asked to choose which nomination they wish to accept, and must reject the other(s).
  5. An election period of at least 30 days will follow the nomination period. The votes will be cast by the Committees and SIGs in the SD, using their normal decision-making practices.
  6. Each Committee will cast votes for two of the candidates, and will be asked to state a preference for one of the two as their primary representative. (This preference will be tallied only if there is a need to resolve a tie.)
  7. The candidate receiving the most votes will be named the Representative for that Steering Division. The candidate receiving the next higher number of votes will be named the Alternate Representative for that SD. Both the first and second place candidates will be named Co-Chairs of the SD.
  8. Tie votes will be resolved by tallying the primary representative preferences for the candidates involved in the tie. If tally also results in a tie, the decision will be made by drawing lots, unless one of the candidates involved wishes to defer to the other(s).
Affiliate Representatives

Two Affiliate Representatives will be elected by the "global" HL7 Affiliates -- the "traditional" affiliate organizations plus the US affiliate. (During the initial election, the HL7 Board is requested to designate a consensus body to nominate and cast votes for the US Affiliate.)

The election process for Affiliate Representatives is:

  1. During a nomination period of at least 30 days, nominations for Affiliate Representatives will be accepted from the affiliate organizations.
  2. Nominees should be prepared to commit at least two hours a week to the TSC, if elected.
  3. HL7 staff will contact nominees to verify their willingness to stand for election, and to solicit a brief nominees "statement" for distribution.
  4. An election period of at least 30 days will follow the nomination period. The votes will be cast the Affiliates, using their normal decision-making practices.
  5. Each Affiliate will vote for one or two of the candidates, depending upon how many Affiliate Representative positions are being filled in that election. (See discussion of member terms, below.)
  6. The one or two candidate receiving the most votes will be named the Affiliate Representative(s), depending upon how many positions are being contested.
  7. Tie votes will be resolved by drawing lots, unless one of the candidates involved wishes to defer to the other(s).
Representative Election Timing

In order to assure the greatest diversity and balance of the representatives on the Technical Steering Committee, the election of Representative Members will be phased, with the Election for Steering Division Representatives coming first, election of Affiliate Representatives second, and appointed TSC members being designated last. These periods may overlap, but the nominations for Affiliate representatives should start after the slate of candidates for SD representatives has been established, and Affiliate representative elections should commence only after the SD elections are complete.

Board-Selected Members

The HL7 Board of Directors will select or appoint two members to the Technical Steering Committee.

  1. The Chief Technology Officer who will hold an ex officio voting position on the Technical Steering Committee.
  2. A Board Liaison to the Technical Steering Committee, which is also a voting position. This position is required only if the recommendation that the TSC Chair be an ex officio voting member of the Board is not accepted. (See below.)
Technical Steering Committee-Appointed Members

The Technical Steering Committee will also appoint two members to the TSC. They are:

  1. An Architecture Review Board (ARB) Representative. The T3F believes that the ARB fulfills a vital "independent" role in HL7 and should have voting representation on the TSC. Normally this representative will be the ARB Chair, but in the event that the Chair is already a TSC member, or declines to serve, another ARB member will be selected.
  2. An ad hoc TSC-Appointed Member will be appointed on a variable term, not to exceed two-years, based on requirements or needs for balance or expertise that the Technical Steering Committee may from time to time identify. This will be a voting position.

Membership Terms

All normal membership terms on the Technical Steering Committee shall be for two years, and will run on a calendar year basis. (See exceptions, below). There are no term limits, members may serve successive terms.

Technical Steering Committee Elections should be held between the "Spring" and "Fall" Working Group Meetings each year, for candidates who will take office in January of the following year. Each year, representatives for two of the four Steering Divisions will be elected as will one of the two Affiliate Representatives. The appointed positions do not need to be staggered.

Vacancies

In the event that a member must resign from the Technical Steering Committee, the following procedures shall be used to fill vacancies:

  1. For SD Representative positions, the Alternate Representative will be designated to serve the remainder of the vacated term, and the Alternate position will be re-filled in the next election cycle.
  2. For Affiliate Representative positions, the Affiliate Council will be asked to name an individual to serve the remainder of the vacated term.
  3. For the Board Liaison and the ARB Representative appointed positions, the appointing body will be asked to fill the vacated position as soon as possible. The initial term of the replacement appointee will run until the second year-end following the appointment.
Term Exceptions

The following exceptions exist for the two-year, calendar-term rule above:

  1. The CTO holds a standing ex officio membership, and therefore that TSC term is dependent upon the term of service as CTO.
  2. The term of ad hoc TSC-Appointed Member will start when the TSC makes the appointment and will end as determined by the TSC, but cannot exceed two years.
  3. During the summer of 2007, elections are planned for all six elective positions. In order to establish staggered terms, two of the four elected SD representatives and one of the two elected Affiliate representatives will be designated to serve an initial "half-term." This designation will be determined by drawing lots.
  4. Because of the desire to have the TSC start functioning in September 2007, the initial terms of the elected and appointed members will be extended by to cover the period from September 16, 2007 through to the nominal start of their terms on January 1, 2008.

Election of Technical Steering Committee Chair

The Chair of the Technical Steering Committee will be elected by the Technical Steering Committee itself. The Chair shall be selected from the voting members of the TSC. There will be no formal designation of a Co-Chair or Vice-Chair for the Technical Steering Committee. The Technical Steering Committee can take whatever steps it wishes to assure coverage when the Chair is unavailable for a particular meeting, including, if it wishes, naming a standing Vice-Chair.

TSC Chair as Member of HL7 Board

The T3F recommends to the Board that the elected TSC Chair be made an ex officio voting member of the Board as the Technical Chair has been in the past. This suggestion arises from concerns that the Board must become a strategic body and defer tactical activities to the CEO, CTO, etc. If the TSC Chair is an active member of the Board, it helps communications in both directions. Even though the Board will be strategic, it still holds full responsibility for HL7's success and the TSC must act to assure that success, and by the nature of its duties, the the TSC will be making Strategic technical recommendations that must be properly represented and understood at the Board.

Term of Office

The Chair will be elected for a two-year term of office, regardless of how long the candidate's membership term has left to run.

In the not unlikely event that the term of office runs longer than the Chair's term as a member, the TSC may use its "TSC-Appointed" position to extend the Chair's membership, or may petition the Board to temporarily expand the TSC membership to allow the Chair to serve out the term of office.

The Technical Steering Committee should seek to establish Chair terms of office that run on a calendar basis. As with regular terms, the term of the initial TSC Chair shall be extended to cover the period from September 16, 2007 through December 31, 2007.

Decision making and delegated decisions

By and large, decisions of the Technical Steering Committee will be made by vote. There are however, tactical decisions, such as approvals for ballot, exceptions to ballot rules, etc. that have, in the past, been assigned to the Technical Chair of HL7 as part of HL7 By-laws or Policies. Such decisions should be assigned to the CTO, using the individual SDs and committees as resources, with the TSC providing a venue for appeal of such decisions.

Relationship of TSC to CTO

In the course of its deliberations, the T3F paid particular attention to the role of a Chief Technical Officer (CTO). Ultimately, the T3F came to the conclusion that the relationship between the CTO and the TSC should mirror the relationship between the CEO and the Board of Directors each acting assure the success of the other.

This decision was predicated on the assumption by the T3F that the TSC would participate in the Board's selection of the CTO and that the following principles will be applied in making a CTO selection, in priority order:

  1. A proven consensus builder
  2. Someone who knows and is known to the HL7 Working Group
  3. Likely to have been a Co-Chair or “facilitator”, but not necessarily required
  4. Have a strong understanding or working knowledge of the technology that HL7 defines and is dependent upon.

In that context, the following motion was unanimously adopted by the T3F.

T3F Motion Unanimously Adopted April 3, 2007

WHEREAS:

  • The task of over-seeing and coordinating the technical activities of Health Level Seven requires the full-time attention of a knowledgeable professional, "Technical Officer";
  • The effective coordination of the various committees and SIGs requires a restructuring of these into three or four sub-groups reporting to an elected Technical Steering Committee;
  • The Technical Steering Committee must assure the continued involvement and support of HL7's Core Resource - volunteer-driven Working Group; and
  • The success of the Technical Steering Committee and the success of the "Technical Officer" are inextricably intertwined, and, further, are essential to HL7's success;

THEREFORE, the Transitional Technical Task Force RESOLVES to recommend:

  • The "Technical Officer" should be recruited to work with and support the Technical Steering Committee in its responsibilities to oversee HL7's technical activities;
  • The "Technical Officer" should report to the CEO and the HL7 Board, and should be a voting member of the Technical Steering Committee.
  • The Chair of the Technical Steering Committee should be be elected by the voting members of the Technical Steering Committee, and selected from within the members of the Technical Steering Committee.
  • The Technical Steering Committee and its Chair should delegate responsibilities and operational decision-making (to be defined later) to the "Technical Officer."
  • The Technical Steering Committee should have a role in recruiting and evaluating the "Technical Officer."

Relationships

Clearly, the central role that the Technical Steering Committee will play within HL7 demands an understanding of the relationships of that group to the rest of HL7. To this end, the T3F has created the following chart. [Note: This graphic has not been updated. Please, mentally, substitute "TSC" for "TD" every placer it appears.]


TDRelationships20070424.gif

[Note: This graphic has not been updated. Please, mentally, substitute "TSC" for "TD" every placer it appears.]

The Technical Steering Committee (TSC) and its four Steering Divisions (SD) are shown in relationship to the Board of Directors (BOD) on the right. The TSC and SDs make up the "Working Group" of HL7, and the relationships between them are discussed in earlier sections of this document.

The left hand portion represents the employees of HL7 and the Staff of AMG, and these relationships are shown for example here and are not considered further in this report.

The committees and SIGs that make up three of the four SDs are entirely made up of volunteers and are formed by petition to and approval of the TSC. The fourth SD, the Technical & Support Services Steering Division (ST on the chart) is made up of committees appointed by the TSC, chaired by a volunteer, but made up of a mix of volunteers, employees and staff. Hence, they sit on the boundary between the Employees and Volunteers, as do the Board-appointed committees.

The most critical concept exposed by this chart, is that the TSC, SDs and committees on the right, and the Staff and Employees on the left cannot be successful in their endeavors without robust productive collaboration between them. HL7 has always been fortunate to have minimal contention and maximum cooperation between its employees, staff and volunteers, and this T3F report is predicated on the continuation of that relationship.

Decision Making Practices

This section documents the proposed set of decision-making practices for the Technical Steering Committee, an elected and Board appointed Committee reporting to the HL7 Board. The TSC will lead by example, and adhere to a set of decision-making practices that ensure consensus, openness, and balance of interest.

Furthermore, the practices as outlined here are designed to enable timely decision-making with an earnest attempt to ensure that input from all affected parties is considered. The Decision-making practices are intended to govern the standard operating procedures of the TSC and are not intended to conflict with rules governing ballot procedure as defined by ANSI and the HL7 Bylaws and Policies and Procedures.

  1. Meetings are open to all interested parties including but not limited to members of HL7, HL7 affiliates, and guests of HL7 as referenced in the HL7 Bylaws – Article 3.02.

    Meetings of the TSC are open to everyone to ensure that viewpoints of all affected parties have an opportunity to be shared and considered. Everyone may have an opportunity to speak; however, the chair may limit discussion to topics that have been identified during the setting of the meeting agenda, or due to time-constraints that may prevent completion of business. If discussion is truncated prior to resolution of the item under discussion, a future time for discussion will be set prior to moving to the next topic. Participants with submitted topics are expected to attend when the purpose or mode of the meeting require their input. Other HL7 members may be asked to attend to provide specific input regarding a particular issue. The following list identifies expected participation by meeting type. All TSC meetings are open; this list simply identifies the anticipated participants.
    • Scheduled/Periodic conference call meetings are attended by persons registered on the TSC email list.
    • TSC Meetings during Working Group Meetings may be attended by any working group meeting attendee. Participants are asked to introduce themselves and identify the nature of their affiliation with HL7.

  2. Venues of Notification.

    All activities will be conducted in a public light with efforts made to ensure ample notification of those interested. The TSC shall utilize two key venues to notify the interested membership of its activities: the TSC's Wiki site and the TSC's website.

    Satisfaction of minimal notification requirements dictates that relevant announcements/materials/etc. be posted to both the Wiki and the website. The Wiki will be used for discussion threads, notifications, new and archived documents, whereas the web server will predominantly be used for archival and document resources (decision documents, minutes, papers, etc.).

    Any use of the terms post, posted, or posting refers to notification subject to these constraints.

  3. Notification of meetings and the intended agenda is provided prior to the meeting.

    Binding decisions can be made only at meetings with the required advance notification; only recommendations and non-binding decisions can be made at special purpose meetings.

    The chair of the TSC shall make every attempt to ensure that all parties with an interest in agenda topics are made aware of the meeting time and location subject to the documented notification requirements. As appropriate, TSC activities will be cross-posted to other HL7 Wiki sites, depending upon the topic and type of meeting as indicated in the following list. Certain meetings are subject to Bylaws guidelines for notification. Please refer to the Bylaws for additional information.
    • Working group meeting agendas are posted in the meeting brochure. A preliminary agenda is developed by Wednesday of the prior working-group meeting and posted with the minutes within 2 weeks. The preliminary agenda is finalized on a scheduled conference call two weeks prior to the working group meeting and posted within 2 business days. Recognizing the dynamic nature of working group meetings, the agenda may require updates. Notification will be satisfied so long as at least two of the following venues are used:
      • E-mail notification by 6:00 pm local time the evening before the event
      • Notification on the bulletin board (near the registration desk) at least 2 quarters prior to the event
      • Announcement in the general session or lunch session prior to the event
    • Scheduled/Periodic telephone conference call meeting agendas are to be posted no later than 24 hours prior to the call. Preliminary agendas are to be determined at the close of each teleconference.
    • The agenda, for either a conference call or working group meeting, will include the purpose of each topic, anticipated discussion time and whether it is intended to set direction or to make a decision.
    • Should the TSC require action between scheduled meetings there are two alternatives. First, a Special Purpose Meeting may be called as defined in the Bylaws (Section 11.04), which requires 30 days notice. Alternatively, the issues may be discussed as an informal group, bringing forward recommendations to the list or as a discussion topic for the next regularly scheduled TSC meeting. Recommendations by the informal group are not binding decisions until acted upon by the TSC.

  4. Decisions made at TSC meetings are recorded in meeting minutes and posted.

    Minutes are recorded and posted for all TSC meetings including the date, time, and location of the meeting, a list of attendees, the intended agenda, a brief summary of discussion topics, and the outcome of proposals made (including vote tallies if votes were taken).

    Minutes from a working group meeting will be posted no later than 2 weeks of the last day of the conference and in compliance with HQ deadlines; minutes from a conference call will be posted within one week of the call.

  5. Decisions made at non-working group meetings (conference calls and special purpose meetings) are summarized during the next working group meeting.

    In the interest of facilitating good communication among the TSC members, those decisions that were made between working group meetings will be summarized and available at working group meetings. This communication will contain, at a minimum, abbreviated summary of the issues involved and the decisions made by the TSC. Any TSC decisions are subject to the practices documented elsewhere in this paper.

  6. . Quorum for TSC meetings: For decision making, the chair (or designate) and at least five other TSC members must be present, including at least two of the four elected sub-group chairs (or their alternates) . For direction setting, the chair (or designate) and at least four TSC members must be present.

    Attendance for all meetings is recorded in the meeting minutes, including the participant name and constituency they represent. The recorder for the meeting is responsible for ensuring minutes are taken and posted. Due to the balanced makeup of the TSC, "Preponderance of Influence" is not viewed as a substantive issue for the TSC. The chair may cast a vote as a tie-breaker.

    In all circumstances, the TSC can have no more than one presiding chair. All other TSC members, act as regular voting members when not presiding. Unlike other HL7 technical committees or SIGs with multiple co-chairs, the chair shall not change within the course of a given meeting.

    Although any issue may be discussed within TSC meeting venues at any time, binding actions cannot be taken without sufficient notification and quorum. Absence of either of these conditions allows the TSC to issue recommendations that must subsequently be ratified by the TSC subject to satisfying constraints placed upon binding decisions.

  7. Decisions made by the Technical Steering Committee are reached using a simple majority vote. The TSC will always strive for consensus in decision-making.

    While decisions are made by simple majority vote, the TSC shall endeavor to make its decisions via a consensus process. For a decision to be called consensus, it must receive two-thirds (66%) majority support. While determining if consensus is being reached, a variety of techniques may be used informally to assess the position of the group, including but not limited to straw poll, Robert's Rules of Order, seeking response to a hypothetical opposing view, and polling each participant to voice their position on the issue.

    When formal votes are taken appointed or elected TSC members shall always receive a vote. For non-binding decisions only, all meeting participants may have the opportunity to vote at the discretion of the chair.

    Once voted, quorum is revisited to adjust for abstentions. Quorum must be met across yeah-s and neah-s for the vote to carry.

    It is recognized that revisiting previously made decisions inhibits TSC progress and should be discouraged. That said, circumstances might exist that warrant re-opening of discussion on a previously visited issue. To dissuade this practice, such re-opening requires a formal motion, second, and simple majority affirmative vote of the TSC as subject to the quorum rules in this document; however, in order for the decision to be considered binding, advance notification, as defined in this document, is required

  8. TSC Members unable to participate in Directorate activities in person may not do so by proxy.

    The Technical Steering Committee does not recognize voting by proxy. There is ample opportunity to support or oppose proposals under consideration through TSC Wiki discussions, email and conference calls. If a member feels strongly enough about a particular topic to want consideration by the TSC, that member shall be present for the topic to be considered. The chair will be sensitive and considerate in attempting to accommodate schedules to ensure the member can be present at the appropriate venue.

    Note: The four TSC members who serve as Representatives of a Steering Division each have an elected Alternate Representative who can attend and vote in TSC meetings when the primary Representative is unable to attend. Votes by Alternate Representatives are not deemed to be proxy votes.

    Statement of Position. Those HL7 members wishing to establish a position on a topic under consideration by the TSC in writing may do so subject to the notification requirements below. Statements of Position received prior-to or during the meeting will be shared by the chair as part of the discussion on the related topic. The chair has the responsibility to voice and represent these positions during relevant discussion, though they are not under obligation to support or defend them. These statements do not carry the weight of a vote and are included as informational items only for consideration by the TSC. All Statements of Position received in electronic form will be included as attachments to the minutes.

  9. The TSC shall rely upon Robert's Rules of Order in the event that formal guidance is needed or requested.

    The TSC intends to ensure the effective and active engagement of all participants. To ensure fair and just participation, the TSC shall follow its documented decision-making practices, falling-back upon Roberts Rules of Order in the event of a question or concern. Since Robert's Rules of Order provides formalism for addressing almost all matters of process, this provides a "backup mechanism" of formality in the event that it is required.

    It is the responsibility of the chair to guide the TSC to an efficient and effective outcome. The TSC shall follow, in this order of precedence, these Decision-making Practices (which cannot conflict with HL7 Policies and Procedures or the HL7 Bylaws), HL7 Policies and Procedures, the HL7 Bylaws, and Robert's Rules of Order. TSC-established decision-making practices can refine the HL7 Policies and Procedures and Bylaws so long as they remain in accordance with those documents.

    In the event that an issue arises where formality is required and other guidance exists, Robert's Rules of Order shall take precedence. This provides a "common denominator" to keep in-check the power of the chair and to confirm the rights of all TSC members.


Quorum Examples

Based upon PIC's Decision Making Practices Document version 1.3, adopted December 1, 2003.

  1. Simple scenario
    6 persons, including two elected subgroup representatives , attend a meeting, including the chair (or their designate).

    Quorum is established and the TSC can conduct its business as usual. All participants are eligible for voting;

  2. Tie scenario
    6 persons, including two elected subgroup representatives,attend a meeting, including the chair (or their designate).

    Quorum is established and the TSC can conduct its business as usual. In the event of a tie this will not constitute a consensus decision, because the consensus majority (66%) criterion has not been met.

  3. Non-representative scenario
    6 persons, not including two elected subgroup representatives, including the chair (or their designate).

    Quorum is not established and the TSC cannot conduct official business, because two members representing an elected subgroup are not present.

Below is a quick reference for meeting configurations. (Note: this table does not have a direct correlation to the scenarios above.) .

Member Designation 1 2 3 4 5 6 7 8 9
Chair or Designate 1 1 1 1 1 1 1 1 1
Elected subgroup representatives 1 2 3 1 2 3 1 2 3
Other Voting TSC members 3 2 2 4 3 2 5 4 1
Is a Quorum established? No No Yes No Yes Yes No Yes No


Tactical Plan to Establish Technical Steering Committee

The T3F recommends the following time-line to the HL7 Board for the establishment of the Technical Steering Committee. If the composition and election processes included in this report are approved by the Board before or during the Board's June Conference call, this schedule provides a reasonable time-line for carrying out the TSC elections in time to allow the restructured TSC to hold its first meeting during the September 2007 Working Group Meeting in Atlanta. (Note that the staging of the nominations and elections are designed to allow the Affiliate constituencies to know who are the Steering Division Representatives before the Affiliate election process begins.)

May 2007 Working Group Meeting

  • T3F to present current recommendations for the formation of the TSC.

May 23, 2007

June through mid-September 2007

  • Thirty days for nominations of SD Representatives. (open June 6; close July 6)
  • Thirty days for election of SD Representatives. (open July 9, close August 8)
  • Thirty days for nomination of Affiliate Representatives. (open July 10, close August 9)
  • Thirty days for Affiliate Representative election.(open August 13, close September 12)
  • Board appoints its representative any time prior to September.

September 2007 Working Group Meeting

  • First official meeting of the TSC. TSC to elect a chair.
  • Terms will be staggered by drawing lots.

Project Plan for an HL7 Architecture

The initial guidance from the Strategic Initiative and the Board suggests that a completely defined, accessible Architecture for HL7 standards is an essential element to developing, promoting and maintaining the inter-operable standards to which HL7 aspires.

The T3F is in full agreement with this suggestion, yet has not found the band-width to do more than pay lip service to this need. This simply reflects inevitable trade-offs between tactical and strategic objectives. In this case, the tactical objective has been to get the Technical Steering Committee "off the ground."

In order to avoid having tactical issues continue to dominate, the T3F will prepare a Project Proposal in the near future to:

  • define HL7's objectives for a effective architecture,
  • do a "gap analysis" between what HL7 has today and what it seeks, and
  • recommend a specific plan of action to achieve the goal.

At one point, the T3F aspired to have a Project Proposal for review at the upcoming Working Group Meeting, but will not meet that objective. At this point it is the T3F's intent to develop such a proposal in coming weeks so that it might be available for Board review this summer.

In preparation for that effort, Berndt Blobel, a member of the T3F, has provided the following background material. It provides a glimpse of what is needed, and a cursory assessment of where HL7 stands in this regard.

Architecture for Inter-operable Health Information Systems

For establishing sustainable and semantically inter-operable health information systems, an appropriate architectural approach has to be developed, referring to approved knowledge and existing standards as much as possible.

Definition

An architecture of a system is a (formal) model of the real system, describing the system's components, their functions and relationships.

Architecture Characteristics

The architecture has to be

  • business-driven (for meeting user requirements and process needs),
  • following a unified process (for definition, design, implementation, evaluation, testing, and maintenance to support semantic interoperability),
  • service-oriented (for meeting business requirements and users' expectations (acceptance) by serving the users' business processes, based on domain knowledge expressed in corresponding concepts and aggregation schemes),
  • model-driven (separating computation-independent models, platform-independent models, and platform-specific models for enabling portability, flexibility, and semantic interoperability),
  • component-oriented (for supporting scalability and flexibility),
  • lawful (for providing user acceptance and trust).

Model Characteristics

In that context, models as reality representation, communication tools, and representations of business interests, intentions, etc., have to possess certain characteristics such as

  • the separation of computation-independent models, platform-independent models, and platform-specific models, always starting with the business model and tackling all views of the ISO 10746 Open Distributing Processing reference model,
  • deriving the models by constraining reference models for information and processes,
  • the consideration of structural and behavioral aspects of the considered system (reflecting the semantic and the pragmatic aspect of information),
  • the provision of appropriate concept representations including the aggregation schemes (rules) at different aggregation levels,
  • the deployment of appropriate (reference) terminologies and ontologies.

HL7's Position in This Space

For those who have wrestled with "Version 3" for the last decade, these are familiar concepts and objectives, most of which have been recognized and some of which have been addressed, if not fully achieved.

For example, HL7 meets some but not all of the paradigms for establishing sustainable and semantically inter-operable health information systems, defined in the Generic Component Model, such as:

  • Component orientation and the distribution paradigm;
  • Unified process of definition, design, implementation, evaluation, testing, and maintenance;
  • Common reference models for information and processes;
  • Common terminologies and ontologies;
  • Separation of logical and technological views by platform-independent and platform-specific models, respectively;
  • Specification of the components' structure and behavior as well as of the rules being applied based on knowledge, concepts and contexts;
  • Enhanced security and privacy services.

HL7 has developed an advanced unified process, the HDF. It provides a model-driven approach, a vocabulary with references to existing terminologies. It is component-oriented at different levels of granularity. HL7 V3 describes most (in future perhaps all) views of the RM-ODP, starting with business requirements (e.g. EHR-S Functional Model), business process models (e.g. Templates, SOA), and thus is, step by step, establishing a service-oriented architecture.

The most obvious weaknesses are immature development in some areas and missing integration between the paradigms and methodologies needed for establishing a sustainable architecture. This is a question of time and development, and the project to be proposed will seek to define how much time, and how much development.