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

Harmonization Process Change

From HL7Wiki
Revision as of 14:54, 22 September 2013 by Gwbeeler (talk | contribs)
Jump to navigation Jump to search

Status of This Page

This page is being drafted to hold a set of updates to the existing Vocabulary and RIM Harmonization Process page, based on experiences and concerns that were raised in July 2013. There are no fundamental changes in the process and rules, but many points have been clarified or extended.

The intended changes will be announced to the Co-Chairs on Monday evening, September 23, 2013, with a request that they be reviewed, and there will be a discussion on this at the Facilitator's Round Table. Ultimately, this page will replace the Vocabulary and RIM Harmonization Process page.

The amended sections are highlighted in yellow below.

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 "announcement" of the Harmonization Meeting and their purpose is issued with at least 30-days advance notice. To that end, the proposals to be reviewed are solicited and posted 30 days in advance, as well. This notice ensures adequate opportunity for review of proposals prior to the harmonization meeting. 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 rare circumstances “emergency” harmonization meetings may be scheduled, but these must still meet the 30-day notification requirement. 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

Proposals to add to or change the HL7 RIM and Vocabulary content must be documented with the submission template provided on the Harmonization page. A submission template will be developed for design patterns and data type flavors which must be used once available. The templates and their packages:

  • indicate the purpose of each field
  • show which fields are required
  • provide a check list for submissions, and
  • provide an example.

Proposals are submitted through the Harmonization web site. 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), from an HL7 Affiliate organization or from an accredited SDO in the health care field.
    A proposal submitted directly by an Affiliate or SDO must still identify the associated HL7 International Work Group, where one applies to the content, and should be submitted, and reviewed by, and, preferably, endorsed by that work group prior to harmonization submission.
  2. Initial proposals not received by this date will not be scheduled for review in the Harmonization Meeting, although submitters of late submissions may appeal this automatic rejection (see ‘Appeals’ below).
  3. Because the RIM and the RIM-controlling vocabulary are under continuous maintenance and are balloted annually, RIM changes for July Harmonization will be limited to changes that arise as a result of ballot reconciliation for the RIM during the May ballot cycle.
  4. Changes to the RIM and RIM-controlling vocabulary content are freely accepted for consideration in March and November Harmonization meetings, but
  5. In order to be acceptable (see Technical Review below), the proposal must:
    • Be sufficiently complete and correct that it could be implemented solely from the information in the Recommendation section of the proposal - without inference or assumption, once approved.
    • Include all elements listed under Required Data Elements (below)
    • indicate changes from the current state of the RIM or Vocabulary (If a new proposal is intended to make a "technical correction" to a previous proposal, the new proposal should not reflect changes from the content that existed before the previous proposal was made.)
  6. 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, perhaps, by reducing its scope.
Jump to top of page

Required Data Elements

Regardless of the content of other fields in the proposal, the Recommendation section of the proposal must be sufficient to implement the proposal. In order to modify or add a Vocabulary or RIM element, the following data elements must be included in the Recommendation section, although a complete proposal will commonly require more data.

  1. RIM Class
    • Class name
    • Parent Class name (if any)
    • At least one attribute
    • Formal naming property Class:Name
  2. RIM Attribute
    • Parent class name
    • attribute name
    • cardinality
    • data type
    • proposed sort location
    • concept domain (if coded data type)
  3. Coded Concept
    • Code System Name
    • Parent code (or indication it is at the 'root' of its code system)
    • Code (or indication concept is abstract)
    • Print Name
    • Definition
    • Formal naming and ordering properties, if any (see proposal review sheet for explicit list by code system)
  4. Concept Domain
    • Concept Domain Name
    • Parent Concept Domain Name (if any)
    • 3+ Examples (or a binding)
    • RIM anchor for Class/Code linked Domains
  5. Value Set
    • Value Set name
    • Primary Code System Name for Content
    • Extensional or Intentional definition
    • Head code (if appropriate)
    • Inclusion (such as "code and all children, transitive closure")
    • Immutability of value set
    • Formal naming and ordering properties, if any (see proposal review sheet for explicit list by code system)

Content-Endorsing Sponsor

All proposals must be endorsed by at least one “sponsor” HL7 International Work Group unless the proposal originates with an HL7 Affiliate or external SDO and either:

  • There is no appropriate Work Group at the HL7 International level to consider the content (consult the MnM committee for a recommendation as to an appropriate Work Group if in doubt).
  • The submitting Affiliate or SDO is invoking the “International Override” rule (see below)

In either of the two cases immediately above, the “sponsor” is the submitting affiliate or SDO.

In addition to this primary “sponsor” Work Group, zero or more additional Work Groups may be identified as “interested parties” because their artifacts or ongoing work is likely to be impacted by the proposal. Where known, these Work Groups should also be listed by the proposal. While endorsement by these additional Work Groups is not necessary for submission, submitters are strongly encouraged to seek such endorsement as it greatly enhances the likelihood of the proposal passing.

International Override

One of the objectives of the harmonization process is encouraging alignment across Work Groups and Affiliate implementations. The expectation of sponsorship by a Work Group and consultation with other affected Work Groups helps to drive towards such consistency. However, this need must be balanced with requirements of the international community to implement in diverse regulatory and cultural environments that may prevent such alignment.

In the event that a sponsor Work Group fails to endorse a harmonization proposal due to a fundamental disagreement with the underlying requirement (i.e. the Work Group doesn’t think the business process or other driver of the change should be supported), an Affiliate or SDO may choose to submit a proposal under its own sponsorship. However, in doing so, they take on an increased onus in the submission process. Specifically the Affiliate or SDO must demonstrate that:

  • They have engaged in robust and open discussion with the objecting Work Groups to elicit a full understanding of the rationale for the objection(s) to the underlying requirement including any proposed alternatives. This understanding must be documented as part of the proposal.
  • They have taken the Work Group(s) objections and proposed alternatives back to their local stakeholders and those stakeholders have re-affirmed the legitimacy of the requirement in their local environment and have identified the local regulatory, architectural or other reasons justifying the requirement. These special circumstances must also be documented as part of the proposal.

In practice, this process is ideally undertaken as a dialog involving multiple consultations between the Work Group and the Affiliate or SDO stakeholders with an objective of finding an agreed way forward. In general, such a process will require weeks or months, not days. This may require that a proposal be deferred to a subsequent Harmonization cycle.

Provided such a process has been followed, and agreement on a solution could not be reached, the objecting Work Groups shall not use their objection to the underlying requirement as the basis for a negative vote during the Harmonization Meeting. However, objections for other reasons (chosen mechanism for meeting the requirement, poor names or definitions, etc.) are still acceptable.

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 complete and correct. Since this is a technical review, the group will not evaluate proposals for their acceptability other than assuring correctly and clearly expressed content.

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

  • Acceptable for review as stands;
  • Acceptable with Mod - proposal needs minor additions or corrections, to be made in a "Final Proposal", to become Acceptable;
  • Rejected as Incomplete - proposal will not be accepted for review because, in the judgment of the reviewers, the proposal could not have been readily implemented based on the Initial Proposal.
  • Rejected as Without Status - proposal not be on the agenda of 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. Further, the summary findings will also be sent directly to the proposal submitter and the Co-chairs of the endorsing Work Group.

If a proposal is "Accepted" or "Accepted with Mod", it will be scheduled on the Harmonization Meeting agenda. If it is listed as "Accepted with Mod", the proponent and endorsing committee are expected to correct the proposal and resubmit it before the Final Proposal Deadline in order to address the concerns from Technical Review. If requested, the Technical Review group will try to find a means to provide assistance in amending "Accepted with Mod" proposal.

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 Work Group, affiliate or SDO must be documented with the date of the endorsement.
  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 altered, except for a reduction in scope and no new issues are introduced.
Jump to top of page

Followup Review

Subsequent to the final proposal deadline, each proposal that was previously found "Acceptable with Mod" will be re-reviewed and recast as either "Acceptable" or "Rejected as Incomplete". These findings will be circulated on the Harmonization list, and sent directly to the proponents and to the Co-chairs of the affected endorsing Work Groups.

Appeals

If a proposal is "Rejected" in either review, it will not be scheduled on the Harmonization Agenda. This ruling can be appealed to the Harmonization Meeting, 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.

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 Item Discussion

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, Vocabulary, Design Patterns, and Data Type Flavors 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, context bindings, etc.)
  • Amending content that is found to be flawed or needs improvement
  • Defining new V3 design patterns or amending existing ones
  • Defining new "universal" Data Type Flavors
  • 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.

Note: Design patterns are not currently subject to ballot, so harmonization is the only means for proposing changes to them.

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


Harmonization Decision Registry

An experimental effort to track decisions that are made during Harmonization and Joint MnM/Vocabulary WG meetings pertaining to Harmonization policy and practice. This effort includes a set of "Harmonization Policy" pages that will be used to categorize and track policy changes made during Harmonization to assist with decision making and to improve the consistency of decision making. The intention is that decisions made during Harmonization meetings will be registered in each appropriate decision classification after the minutes for the Harmonization meeting have been posted and approved.

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.
Retrieved from "https://wiki.hl7.org/w/index.php?title=Harmonization_Process_Change&oldid=78199"