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 "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. If a terminology is curated and published by an organization external to HL7 (e.g. LOINC, SNOMED, ICD, etc.) there are additional requirements that may need coordination with the HL7 Terminology Authority (HTA), wuch as requests for new content in these terminologies. The HTA templates and forms for these must be used and are available at HTARequest. A submission template will be developed for design patterns and data type flavors which must be used once available. Use the templates and their packages developed for Harmonization, which have:

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

(In general, the content of individual harmonization proposals is not maintained on this wiki. See Supporting Wiki Pages below.)
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.)
    • If proposal involved external terminology, indicate that the necessary coordination with HTA has been initiated or completed.
  6. If endorsement of the proposing Work Group is not yet final (and is required under rule #1), 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

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 (and indication whether the 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)
    • Optional binding and binding realm for value set
  6. External Terminologies
    • Compliance with IP restrictions and requirements
    • HTA Documentation for requests for changes, additions, or promotions of content to international releases

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 compete 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 "Acceptable" or "Acceptable with Mod", it will be scheduled on the Harmonization Meeting agenda. If it is listed as "Acceptable with Mod", the proponent and the 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 "Acceptable with Mod" proposal.

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 Work Group, affiliate or SDO 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.
  4. Must include HTA template if required for external terminology

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

Overall Process Step/Flow Summary

This is a very short step-by-step summary of the overall process steps for producing new content subject to harmonization and the approvals and processing thereafter through final release, as currently implemented (summer 2016). The details of these steps are contained in the writeup above.

  1. Decisions at a Working Group Meeting to prepare harmonization proposals; these are announced and described very briefly during the Thursday Night Facilitator RoundTable meeting at the WGM in order to get a sense of the size of the upcoming Harmonization meeting for planning purposes.
  2. Facilitator works with WG to prepare proposal(s).
  3. Facilitator (or other submitter) uploads initial proposals at the "Initial Proposal" link on the Harmonization Event page prior to the announced deadline. These proposals should be complete as far as content, but may be missing final approvals, or editorial refinement. The link is disabled at the deadline, thus if it is missed, the proposal can no longer be submitted for the technical review of the initial proposals; the train will have left the station.
  4. Harmonization team reviews the submitted initial proposals, and notes issues, along with a judgement as to whether or not the proposal is acceptable, and if not, what changes need to be done before it is acceptable. This feedback is sent to the submitters and the Harmonization List shortly after the Technical Review conference call of the Harmonization team.
  5. Facilitators (or other submitters) must adjust the proposals based upon the feedback from Technical Review. This may result in a proposal being withdrawn, or if acceptable As-Is, not changes at all.
  6. Finalized proposals must be uploaded to the Final Proposal upload link on the Harmonization event page prior to the final deadline. Late submissions cannot be accepted, as the time between the deadline and the Harmonization meeting is needed to prepare the meeting package. The Final Proposal upload link is disabled after the deadline time has passed. Note that Initial proposals that are acceptable As-Is do not have to be uploaded again through the Final link.
  7. Meeting package is distributed at least 12 hours prior to start of Harmonization Meeting.
  8. Harmonization meeting is held, as per rules and procedures outlined above. Note that any proposals that are updated during the meeting (either while the call is ongoing, or in overnight work) MUST be emailed to Karen and also the Harmonization list so that the final updates can be integrated into the final package, and are not lost when the most recent voted updates are processed.
  9. After the meeting, the approved proposals are applied to the V3 and V2 repositories to produce the new content. This is attempted to be accomplished as quickly as possible, in just a few days.
  10. The newly updated content is assembled into a Quality Assurance package, along with the annotated approved proposals from the meeting, and the meeting minutes and voting summary. This package is distributed to the submitters and cochairs and the Harmonization List.
  11. The Quality Assurance review is a five day review by submitters to verify technical accuracy of the application of the approvals to the repositories. The objective is to verify the accuracy off the implementation as per the voted approvals; issues with the approved proposals themselves noted ex post facto during this period cannot be addressed unless they are strictly technical issues, such as clear word misspellings in the original submission, duplicate code values so that the proposed code cannot be inserted as submitted, wrong update of a proposal used, etc. Missing or wrong material that went through the harmonization approval process without being identified, and that is only noted during the QA review, must be submitted as new proposals in the following cycle. EVERY proposal must have an explicit email to the harmonization team or leader asserting that the applied content was examined for accuracy and either is OK, or any issues are noted and must be corrected. This feedback is required, and if it is not received, the cochairs of the sponsoring workgroup will be contacted for this information. Note that to validate the V2 QA release, you need to open the Chapter 2C Word document in the QA package, and to validate the V3 proposals you'll need to open the coremif file in a tool such as RoseTree to inspect the content.
  12. The feedback from the QA review is processed, with any technical accuracy issues addressed to update the master content for V2 and V3.
  13. As soon as possible, preferably in a few days, the final release of the V2 and V3 content is generated. The V3 content is uploaded to gForge in the RIM Design Repository area, and the V2 updated content in the format of the Chapter 2C output is sent to the harmonization list.
  14. The Harmonization cycle is closed.

Supporting Wiki Pages

In general, Harmonization information is not maintained on this Wiki. It is available from the HL7 Harmonization web page. However, an experimental effort to summarize the proposed Harmonization changes and their management on this Wiki 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=Vocabulary_and_RIM_Harmonization_Process&oldid=137108"