MnM Minutes CC 20100611
M&M Conference Call Noon Eastern Time (Date above)
Attendees
Beeler (GWB), McKenzie (LM), Nelson (DN), Seppala (GS), Stechishin (AS)
- Called to order at 12:05 Eastern
Agenda
- Approve Minutes of prior meetings on May 28, June 3 and June 10, 2010.
- Policy Change on Deprecating RIM content - Beeler
- Hot Topic: CMET Management by MnM - Stechishin, Nelson & Beeler
- Other Business
- Review Action Items
Motion: Agenda accepted (LM/GS) unanimous
Approve Minutes
- May 28 (GS/AS) unanimous
- June 3 ((LM/AS) unanimous
- June 10 (AS/LM) unanimous
Policy Change on Deprecating RIM content - Beeler
Previous to now, once the RIM version had been published for committee use, no element of that RIM could be removed without first being deprecated for a period. With the advent of annual voting on the RIM, and the opportunity for recently added content to be challenged in a forthcoming ballot, we wish to propose that M&M endorse the following resolution to the TSC.
Resolution:
Motion:
The RIM is being managed by a combination of changes through Harmonization and approval through Ballot. A new Normative RIM is approved every year, with only those things that have been added or had "substantive" change being "in scope" for the ballot. Additions or changes to a version of the RIM that are not yet "Normative" may be removed from the next version as a consequence of Ballot reconciliation and Harmonization without first deprecating these changes or additions. Changes or additions that have become Normative because they are in a version of the RIM that passes Normative ballot will continue to require formal Deprecation before they can be removed.
In order to protect Work Groups that may have begun to use the removed content, following safe-guards will be implemented:
- The only additions or changes that can be removed are those removed as a consequence of reconciling a Negative vote on an item that was "in scope" in the ballot
- In order to flag items that might subsequently be removed by such an action, MnM will add an "OpenIssue" to that element in the RIM or Vocabulary that states: "This element has been changed, or added and is not yet Normative."
- When the decision to remove an element or elements has been made, MnM will notify the "Co-chairs list" and "International list" that this action will be discussed in a Harmonization meeting (and when that meeting is scheduled.
- MnM will undertake to the recent ballot(s) to determine whether the item(s) to be removed have been used in a balloted static model. If any are identified, the affected Work Groups will be notified.
(AS/GS) unanimous
Note:
There are several RIM additions that were agreed to during the January 2010 WGM, that were applied to the RIM during the March 2010 Harmonization Meeting and first appeared in RIM 2.31. In order to reconcile Negative votes from the 2010May ballot, these items now need to be removed from RIM 2.32 that will be proposed as RIM Release 3 (subject to second ballot). These removals still need to be endorsed in Harmonization in August 2010, and RIM Release 3 will be re-balloted in the 2010Sep ballot cycle.
Assuming that these proposals are approved, the ability to remove them means that the Normative RIM for the next two years will not contain "Deprecated" items that were NEVER in a Normative RIM.
Hot Topic: CMET Management by MnM (Stechishin & Beeler)
A Hot topic has be created to serve as basis for this Discussion.
General Discussion:
Awareness within the Work Groups is a major issue, localized CMETs caused issues when the WG brought them back into the Common list. The master list and centralized management was created as a mechanism to improve the overall quality.
The group discussed the need for a patterned ID, but did not feel it to be a requirement.
Some requirements:
- Register the name like A_FooBar and attribution like "Identified"
- WGs tell us the the Identifiers will be
- Manage the attribution level name and the definition of what that attribution level should contain
- There was some discussion on whether an attribution level versus the selected name could be verified
- Assurance that the models are rooted in the correct class and associations for Role
- Assure that models continue to exist, OR drop from the registry
- Maintain a COCT identifier registry for those who wish to use it
The group discussed the value of segregating "universal" (across all domains) use from "local" (specific to the domain creating the CMET) use. The new model reference capability addresses the requirement for local use.
LM preferred to eliminate the COCT domain and use relevant domain identifier (i.e PRPA for for R_Patient)
GWB: Are/Should names be based on RIM Class and classCode of the entry point
- DN: no
- R_AssignedPerson instead of R_Nurse - state the principle, this is manual verification point
GS had a general comment, the whole CMET balloting process is very confusing, differs from how other documents are balloted - mechanism for managing needs improvement.
Lore: FM had a constrained CMET that did not match the universal and caused the creation of a second universal CMET. A warning should be issued when more constrained CMETs contain attributes that don't exist in the CMET from which it is derived.
Other Business
Review Action Items For MnM
Note the following list, and amend the list to assign selected items:
Adjourned
- 12:58 Eastern
