This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Vocabulary and RIM Harmonization Process

From HL7Wiki
Jump to navigation Jump to search

Background and Objectives

When HL7 first considered developing a single Reference Information Model (RIM) for use in all of the HL7 technical committees (as they were then known), it adopted a process of "RIM Harmonization" to assure that:

  • There was a formal process for review and adoption of change proposals
  • The process would include representation from all interested groups within HL7
    (and from external Standards Development Organizations (SDOs) that wished to collaborate)
  • The representatives would reach consensus before approving a proposal
  • An updated, documented, "approved" RIM would be available at each HL7 Working Group Meeting to allow progress on the RIM-based standards being developed in HL7

The first Harmonization Meeting was held July 8 & 9, 1997 in Indianapolis, Indiana. Since then there has been at least one "interim" Harmonization Meeting between each pair of Working Group Meetings. By 1999, when Vocabulary content became part of the core definition of the RIM classes, the scope was extended to include Vocabulary, and this dual responsibility has remained ever since. Most recently in 2011, the scope was been further extended to also support harmonization of “RIM design patterns” and data type "flavors" defined in the universal realm.

HL7 International and its affiliates have agreed that certain portions of the content maintained via the Harmonization process will be managed only at the international level. This means that affiliates cannot create their own changes or artifacts independent of the harmonization process. The content subject to this “Harmonization only” rule includes the RIM information model itself, all Concept Domains, all “universal” context bindings, and data type flavors defined for use within "universal" HL7 standards. This stance has been taken to ensure a base level of consistency in all HL7 implementations, irrespective of jurisdiction.

Approval Process

As with all formal processes, a formal declaration of the Harmonization Meeting and their purpose is issued with at least 30-days advance notice. The specific scheduled date of these meetings is determined well in advance of the meeting and no later than the end of the Working Group Meeting prior to the Harmonization Meeting. In general, the harmonization schedule is published as part of the Publishing Calendar posted on the HL7 web site.

When the Meeting is formally announced, the details are listed and the proposal posting service is enabled on the Harmonization Event page on the HL7 web site.

Jump to top of page

Submission Process and Schedule

Change proposals for the HL7 RIM and Vocabulary content must be documented with the submission template provided on the Harmonization page. The template and its package:

  • indicates the purpose of each field
  • shows which fields are required
  • provides a check list for submissions, and
  • provides an example.

Proposals are submitted through the Harmonization page. When posted, they are given a unique name, they are added to the posted list of proposals, and a notice of posting is sent to the HL7 Harmonization List Server. Interested parties should subscribe to the Harmonization list.

Jump to top of page

Initial Proposal Deadline

The deadline for initial proposal submission is set for 11:59 PM (Eastern time) on the Sunday four weeks or more before the scheduled Harmonization Meeting. The e-mails to the Harmonization list constitute the "Agenda Notice" for substantive items to be considered at the meetings.

Initial Proposal Rules:

  1. Proposals must be received from a Work Group that has "standing" in the forthcoming meeting (see Representation discussion below)
  2. Initial proposals not received by this date will not be scheduled for review in the Harmonization Meeting
  3. In order to be acceptable (see Technical Review below), the proposal must be sufficiently complete and correct that it could be implemented from the information in the proposal, once approved.
  4. If endorsement of the proposing Work Group is not yet final, such endorsement must be completed before the Final Content Deadline and the endorsement must not change the proposal in such a way as to alter the scope and intent, as expressed in the initial proposal, except by reducing its scope.
Jump to top of page

Technical Review

Within ten days of the Initial Content Deadline, a Technical Review Panel will be convened to assess the completeness and correctness of the proposals received. The panel is made up of representatives from the MnM, Vocabulary, International, and individuals who must "implement" the proposals.

The objective of the Technical Review is to evaluate each of the proposals against the "rules" cited above, particularly the rule on being compete and correct. Since this is a technical review, the group will not evaluate proposals for the acceptability correctly expressed content.

As a result of their deliberations, the Technical Review will find each proposal as:

  • Accepted for review as stands;
  • Accepted with Mod - seeking minor additions or corrections as part of a "Final Proposal"
  • Rejected as Incomplete for review because, in the judgment of the reviewers, the proposal could not have been readily implemented based in the Initial Proposal.
  • Rejected as Without Status for the meeting because the proposal was received late, or because the proposal was not from a Work Group with standing at Harmonization.

Results of the Technical Review will be posted to the Harmonization list within 24 hours after the Technical Review meeting.

If a proposal is "Rejected" in this review, it will not be scheduled on the Harmonization Agenda. This ruling can be appealed, in order to seek to have the proposal reinstated. Although the appeal will be voted on at the beginning of the Harmonization Meeting, notice of the intent to appeal must be sent to the Harmonization list at least four working days prior to the meeting. This notice will allow interested parties to participate in the appeal and, if accepted, the final review.

If a proposal is "Accepted", it will be scheduled on the Harmonization Meeting agenda. If it is listed as "Accepted with Mod", the proposing committee is expected to correct the proposal and resubmit it before the Final Proposal Deadline in order to address the concerns from Technical Review.

Jump to top of page

Final Proposal Deadline

The deadline for initial proposal submission is set for 11:59 PM (Eastern time) on the Sunday one week or more before the scheduled Harmonization Meeting. Any proposal that was received prior to the Initial Proposal Deadline may be updated by the proposing work group. The rules for what constitute acceptable changes or content for "final" proposals follows.

Final Proposal Rules:

  1. The endorsement of the proposing committee MUST be documented.
  2. Changes requested from Technical Review must have been made.
  3. Other changes are acceptable so long as the fundamental intent and scope of the proposal is not unaltered, except for a reduction in scope.
Jump to top of page

Harmonization Meeting

Prior to the meeting, the Final Proposals will be assembled and packaged along with a spread sheet to establish the agenda and facilitate review. Meetings are held during conference calls (supported by GoToMeeting screen-sharing) of four hours duration comprised of two sessions with a mid-meeting break. At the beginning of each session, the quorum and voting roles will be established and documented. At the beginning of the first session on the first day, the floor will be "open" for appeals to "rejections" during Technical Review.

Jump to top of page

Amendment During Meeting

A primary factor in the success of the Harmonization process to date has been the ability to reach true consensus during the discussions. This is only possible because the proponent has the opportunity to amend a proposal during review in order to meet concerns and issues raised by other participants.

In the past, the vast majority of proposals have been modified in some fashion during the meeting. Most modifications have been minor, but some have involved substantial re-factoring of a solution. In general, the intent and scope of the proposal is not changed, except perhaps to reduce scope.

Jump to top of page

Proponent Presence Required During Review

In order for the consensus process and amendment to work, the it is essential that a representative of the proposing Work Group be present and that person be authorized to accept such amendments to the proposals. For that reason,

  • NO proposal will be considered during the meeting unless a representative of the proposing Work Group is present throughout the discussion and voting
Jump to top of page

Ratification of Universal Value Set Bindings by HL7 International Council

Context bindings of Concept Domains to specific Value Sets in the "universal" (UV) binding realm become required for use by all HL7 affiliate realms. Therefore, with the exception of those Code Systems that provide concepts for the RIM and data types "CS" attributes and components, any context bindings in the universal binding realm approved during Harmonization are "provisional" subject to ratification by the International Council.

Jump to top of page

Adoption and Publication

As soon as possible after the meeting the results of the meeting - amended proposals, spread sheet documentation of actions and minutes will be assembled and distributed through the Harmonization page.

Jump to top of page

"Membership" - Representation, Voting, Quorum

Participation in Harmonization is made up of representatives from specific Work Groups plus a representative of the International Affiliates. The meeting is Chaired by a Co-Chair of MnM or Vocabulary who does not vote as a representative during the meeting.

Representation of Work Groups and Stewards

Work Groups that have "standing" for Harmonization and who, therefore, are entitled to submit proposals and to be represented at the meeting include:

  • Specifically Designated Groups
    • Vocabulary Work Group (Steward)
    • Modeling and Methodology Work Group (Steward)
    • Structured Documents Work Group
    • International Representative (Steward)
    • Domain Experts Steering Division
    • Structure & Semantic Design Steering Division
  • Proponent Work Groups -- Any Work Group that has content in the current Ballot Cycle or that has an approved project developing content for future DSTU or Normative ballot.

Work Groups designated as "Steward" in the list above have additional responsibilities in regards to the quorum and voting rules.

Designation of Representatives

Representatives must usually be co-chairs, modeling facilitators or vocabulary facilitators of their respective committees. In the event such a representative cannot attend the harmonization call, the committee may select an alternate representative whose name must be submitted to the harmonization list by a co-chair or facilitator of the respective committee. The exception to this rule is the International Representative who shall be a non-U.S. representative able to attend the meeting who is not acting in another capacity.

Jump to top of page

Quorum Requirements

The quorum rules for a Harmonization Meeting involve a combination of the following rules:

  • One representative from each of the stewards listed above MUST be present
  • A representative of the proposing Work Group MUST be present
  • No individual can represent more than ONE group in a particular vote
  • The meeting Chair has no vote and cannot vote to resolve a tie.
    • Therefore, a tie vote will be treated as a vote against the proposal.
  • The minimum number of available votes is six (6).
Jump to top of page

Voting - Simple- and Super-Majority

Harmonization votes are determined by a simple majority of the votes available, except in the instance that one of the "Steward" representatives votes Negative. In that circumstance, a super-majority of 2/3rds is required to pass the proposal.

This rule is rarely invoked. It exists in order to allow the Stewards" to raise strong objections when they perceive that adoption of a proposal will threaten the integrity of the RIM or Vocabulary content, or does not qualify as a "Universal" proposal.

Jump to top of page

Harmonization vis-a-vis Balloting

Since many V3 ballots involve newly defined vocabulary content, and the RIM itself is now re-balloted on an annual basis, the question inevitably arises as to the differences between Harmonization and Ballot, and which process should one follow in order to object to one of these constructs.

The answer goes back to the objectives of Harmonization. As noted earlier Harmonization is intended to be an interactive, consensus-building process for adopting changes to the RIM and Vocabulary on a timely basis to meet the needs of standards being prepared for Ballot. In contrast, the Ballot is a process to encourage detailed review and approval of proposed standards.

Thus, Harmonization should be used for:

  • Adding new content to the RIM (classes, attributes, associations, etc. ) and Vocabulary (code systems, codes, concept domains, value sets, etc.)
  • Amending content that is found to be flawed or needs improved documentation
  • Propose solutions for "Hot Topic" issues in the RIM

And the Ballot is the appropriate place to:

  • Comment/change minor wording in new RIM content, when it is "in scope"
  • Vote against new (and therefore "in scope") RIM changes that do not appear correctly structured
  • Vote against the use of RIM or Vocabulary constructs that inappropriate for a particular V3 design.
Jump to top of page

Ballot "Scope" for RIM and Vocabulary elements

When included in balloting, the degree to which RIM and Vocabulary elements are "in scope" is determined by the nature of the ballot and the elements. Specifically:

  1. Vocabulary content is not formally balloted.
    • Thus vocabulary elements are only "in scope" when they arise in the context of some other ballot.
    • Therefore, Vocabulary changes are best sought through Harmonization.
  2. The RIM is undergoing a maintenance ballot each year
    • The "new" RIM may include new constructs and vocabulary that were accepted in Harmonization.
    • Only that RIM content and RIM-vocabulary that have been changed since the last ballot are in scope for these ballots.
      RIM-vocabulary includes the content of code systems bound to RIM attributes with a CS data type plus other constraints (Concept Domains) against RIM attributes
  3. RIM and Vocabulary elements used in designs being balloted are subject to negative vote as to the appropriateness of the element to fulfill the design function.
    • Note that this is a vote against the use of an element rather than against the element itself.
    • The committee reconciling such votes may choose to change the elements used, or seek a Harmonization change to make improve the appropriateness of the chosen elements.
Jump to top of page

Supporting Wiki Pages

An experimental effort to summarize the proposed Harmonization changes and their management within MnM has been undertaken. The initial effort is a set of "Harmonization Summary" pages that are "auto-generated" from the spreadsheet used to manage harmonization proposals. The summaries are maintained in a set of Wiki categories:

Jump to top of page

Prior Page Content and History

This Page was initiated by Russ Hamm May 17, 2010

I moved two prior Harmonization-related sub-items (that had been listed under MnM on the "Main page") here, because as this page is completed, this is where those links belong. GWBeeler

  • Harmonization Wiki Template
    This template came into being in 2006, but has never been formally used as a harmonization source path. I (GWBeeler) suggest this be dropped for the following reason(s):
    • The current proposal management process is highly dependent upon being able to extract 'specific data fields from the Word document, and the Wiki template has no facilities that lend themselves to reliable automated parsing.
    • We should focus current improvements on the updating of the Word "template"
  • Vocabulary Harmonization Tool
    The Vocabulary Maintenance Language remains a main-stay of vocabulary harmonization processing, but the specific tool linked from here has no active users, and therefore, I (GWBeeler) suggest this link be dropped.