|
|
| Line 7: |
Line 7: |
| | The amended sections are highlighted in yellow below. | | The amended sections are highlighted in yellow below. |
| | =Background and Objectives= | | =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= | | =Approval Process= |
| − | As with all formal processes, a formal <span style="background:#FFFF00">"announcement"</span> of the Harmonization Meeting and their purpose is issued with at least 30-days advance notice. <span style="background:#FFFF00">To that end, the proposals to be reviewed are solicited and posted 30 days in advance, as well.</span> 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 [http://www.hl7.org/special/committees/publishing/schedules.cfm 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 [http://www.hl7.org/events/harmonization/index.cfm?ref=nav Harmonization Event] page on the HL7 web site.
| |
| − | :{{to-top}}
| |
| | ==Submission Process and Schedule== | | ==Submission Process and Schedule== |
| − | <span style="background:#FFFF00">Proposals to add to or change</span> the HL7 RIM and Vocabulary content must be documented with the submission template provided on the [http://www.hl7.org/events/harmonization/index.cfm?ref=nav 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 [http://www.hl7.org/events/harmonization/index.cfm?ref=nav 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.'''''
| |
| | :{{to-top}} | | :{{to-top}} |
| | ===Initial Proposal Deadline=== | | ===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==== | | ====Initial Proposal Rules==== |
| − | #Proposals must be received from a Work Group that has "standing" in the forthcoming meeting (see [[#.22Membership.22_-_Representation.2C_Voting.2C_Quorum|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.
| |
| − | #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).
| |
| − | #Because the RIM and the RIM-controlling vocabulary are [[RIM Maintenance and Tooling Documentation#RIM Balloting Using ANSI Continuous Maintenance Process|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.
| |
| − | #Changes to the RIM and RIM-controlling vocabulary content are freely accepted for consideration in March and November Harmonization meetings, but
| |
| − | #In order to be '''acceptable''' (see [[#Technical_Review|Technical Review]] below), the proposal must:
| |
| − | #*Be sufficiently complete and correct that it could be implemented <span style="background:#FFFF00">'''solely from the information in the Recommendation section of the proposal - without inference or assumption'''</span>, once approved.
| |
| − | #*<span style="background:#FFFF00">Include all elements listed under [[#Required Data Elements|Required Data Elements]] (below)</span>
| |
| − | #*<span style="background:#FFFF00">'''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.)</span>
| |
| − | #If endorsement of the proposing Work Group is not yet final, such endorsement must be completed before the [[#Final Content Deadline|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.
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | ====Required Data Elements==== | | ====Required Data Elements==== |
| − | <span style="background:#FFFF00">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.</span>
| |
| − | #RIM Class
| |
| − | #*Class name
| |
| − | #*Parent Class name (if any)
| |
| − | #*At least one attribute
| |
| − | #*Formal naming property Class:Name
| |
| − | #RIM Attribute
| |
| − | #*Parent class name
| |
| − | #*attribute name
| |
| − | #*cardinality
| |
| − | #*data type
| |
| − | #*proposed sort location
| |
| − | #*concept domain (if coded data type)
| |
| − | #Coded Concept
| |
| − | #*Code System Name
| |
| − | #*Parent code (or indication it is at the 'root' of its code system)
| |
| − | #*Code (and indication if concept is abstract)
| |
| − | #*Print Name
| |
| − | #*Definition
| |
| − | #*Formal naming and ordering properties, if any (see proposal review sheet for explicit list by code system)
| |
| − | #Concept Domain
| |
| − | #*Concept Domain Name
| |
| − | #*Parent Concept Domain Name (if any)
| |
| − | #*3+ Examples (or a binding)
| |
| − | #*RIM anchor for Class/Code linked Domains
| |
| − | #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=== | | ===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. <span style="background:#FFFF00"></span>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==== | | ====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=== | | ===Technical Review=== |
| − | Within ten days of the [[#Initial Content Deadline|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. <span style="background:#FFFF00">Further, '''the summary findings will also be sent directly to the proposal submitter and the Co-chairs of the endorsing Work Group.'''</span>
| |
| − |
| |
| − | If a proposal is "Accepted" <span style="background:#FFFF00">or "Accepted with Mod"</span>, 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. <span style="background:#FFFF00">If requested, the Technical Review group will try to find a means to provide assistance in amending "Accepted with Mod" proposal.</span>
| |
| | | | |
| | ===Final Proposal Deadline=== | | ===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|Initial Proposal Deadline]] may be updated by the proposing work group. The rules for what constitute acceptable changes or content for "final" proposals follows.
| |
| − |
| |
| − | <big>'''Final Proposal Rules:'''</big>
| |
| − | #The endorsement of the proposing Work Group, affiliate or SDO '''must''' be documented with the date of the endorsement.
| |
| − | #Changes requested from Technical Review must have been made.
| |
| − | #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.
| |
| − |
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | ===Followup Review=== | | ===Followup Review=== |
| − | <span style="background:#FFFF00">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.</span>
| |
| | | | |
| | ====Appeals==== | | ====Appeals==== |
| − | If a proposal is "Rejected" in <span style="background:#FFFF00">'''either review'''</span>, 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.
| |
| | | | |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | ==Harmonization Meeting== | | ==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 [[#.22Membership.22_-_Representation.2C_Voting.2C_Quorum|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|Technical Review]].
| |
| | :{{to-top}} | | :{{to-top}} |
| | ===Amendment During Meeting=== | | ===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.
| |
| | :{{to-top}} | | :{{to-top}} |
| | ===Proponent Presence Required During Item Discussion=== | | ===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,
| |
| − | :'''<big>NO proposal will be considered during the meeting unless a representative of the proposing Work Group is present throughout the discussion and voting</big>'''
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | ===Ratification of Universal Value Set Bindings by HL7 International Council=== | | ===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.
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | ==Adoption and Publication== | | ==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 [http://www.hl7.org/events/harmonization/index.cfm?ref=nav Harmonization page].
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | ="Membership" - Representation, Voting, Quorum= | | ="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== | | ==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=== | | ===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.
| |
| | | | |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | ==Quorum Requirements== | | ==Quorum Requirements== |
| − | The quorum rules for a Harmonization Meeting involve a combination of the following rules:
| |
| − | * One representative from each of the stewards [[#Representation of Work Groups and 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).
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | ==Voting - Simple- and Super-Majority== | | ==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.
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | =Harmonization ''vis-a-vis'' Balloting= | | =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 [[#Background and Objectives|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.
| |
| | | | |
| | :{{to-top}} | | :{{to-top}} |
| | ==Ballot "Scope" for RIM and Vocabulary elements== | | ==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:
| |
| − | #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.
| |
| − | #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''
| |
| − | #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.
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
| | | | |
| | =Harmonization Decision Registry= | | =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.
| |
| − |
| |
| − | * [[CodeSystemDecisionRegistry]] - Holds the Harmonization Policy pertaining to Code Systems
| |
| − | * [[ValueSetDecisionRegistry]] - Holds the Harmonization Policy pertaining to Value Sets
| |
| − | * [[ConceptDomainDecisionRegistry]] - Holds the Harmonization Policy pertaining to Concept Domains
| |
| − | * [[BindingDecisionRegistry]] - Holds the Harmonization Policy pertaining to Bindings
| |
| − | * [[HarmonizationPolicyDecisionRegistry]] - Holds the Harmonization Policy pertaining to overall Harmonization policy
| |
| | | | |
| | =Supporting Wiki Pages= | | =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:
| |
| − | * [[:Category:ActiveHarmonizationSummaries]] holds the current summary for the next scheduled Harmonization Meeting.
| |
| − | * [[:Category:ClosedHarmonizationSummaries]] holds the previous summaries for the next scheduled Harmonization Meeting as well as summaries for prior meetings.
| |
| − | * [[:Category:HarmonizationSummaries]] holds the template for these summaries as well as all "active" or "closed" summaries.
| |
| | :{{to-top}} | | :{{to-top}} |
| | | | |
