Difference between revisions of "MnM Minutes CC 20120627 Harmonization Tech Review"
| (4 intermediate revisions by the same user not shown) | |||
| Line 16: | Line 16: | ||
The proposal set included one item that sought to make changes in the ActClass code hierarchy, and might have included another proposal (that was not formally submitted by the deadline) to change the ActRelationshipType codes. This led to the discussion of MnM's intent to limit RIM changes (including changes to the code systems that are referenced by RIM attributes typed with data type CS) to only those changes needed to reconcile negative votes arising from the annual May Ballot cycle RIM Normative ballot. Although this proscription has been in place for several years, it is not well documented. | The proposal set included one item that sought to make changes in the ActClass code hierarchy, and might have included another proposal (that was not formally submitted by the deadline) to change the ActRelationshipType codes. This led to the discussion of MnM's intent to limit RIM changes (including changes to the code systems that are referenced by RIM attributes typed with data type CS) to only those changes needed to reconcile negative votes arising from the annual May Ballot cycle RIM Normative ballot. Although this proscription has been in place for several years, it is not well documented. | ||
| − | The group agreed that this should be clearly documented on the Wiki and expressly listed in the [[Vocabulary and RIM Harmonization Process]] page. Along with these minutes, changes were made to the | + | The group agreed that this should be clearly documented on the Wiki and expressly listed in the [[Vocabulary and RIM Harmonization Process]] page. Along with these minutes, changes were made to the [[Vocabulary and RIM Harmonization Process#Initial Proposal Rules| Harmonization Initial Proposal Rules]] and to the Wiki [[RIM_Maintenance_and_Tooling_Documentation#RIM_Balloting_Using_ANSI_Continuous_Maintenance_Process|documentation of RIM Maintenance procedures]]. |
| − | == | + | ==Incomplete Documentation of Code System Changes== |
| − | + | Discussion of proposal item "2012.PC.RS02" to "move" the "concern" (CONC) ActClass code within the hierarchy noted that although the proposal was understandable, it was not well enough documented that it could be interpreted unambiguously. It was noted that this proposal had, as have others in the past, used the '''''Vocabulary Check List''''' that is part of the harmonization template as a means to document intended content. | |
| − | + | The group wishes to emphasize that the check list is intended solely as an ''aide memoire'' for the proponent and that each element in the list should result in an "entry" in the documentation of the desired changes. | |
| + | |||
| + | In the proposal cited here, there should have been a detailed documentation of all data elements for the change including: | ||
| + | *Identification of the Code System that is involved by name, and (preferably) by code system OID | ||
| + | *Identify each code being deprecated, by code, and provide a rationale for the deprecation. This rationale should include recommendations for how users of the deprecated element should represent their content in the future. | ||
| + | *In this instance, the equivalent concepts for a set of codes was being "moved" by deprecating the prior coded concept and replacing it with a new code that has similar semantics. For '''each of the new codes''' the proposal should include: | ||
| + | ** A new coded concept including its print name and definition; | ||
| + | *** The new print names should differ from the old in order that searches will distinguish them | ||
| + | ** Designation of the "parent" coded concept under which these codes will be placed in the hierarchy; | ||
| + | ** Because these are ActClass codes there needs to be a specification of the '''Name:Class''' property of the codes. (In this case they can be the same as that assigned to the codes that are being replaced.) | ||
| + | ** Because these codes are part of a "class code" or "type code" hierarchy a values set should be defined that includes this code and all of its future children, and whose name is ActClassPrintName. The name is a ''pro forma'' construct using the code system name concatenated with an upper-camel-case representation of the print name for the code. | ||
| + | |||
| + | The harmonization team agreed that we need to incorporate detailed instructions like this for all the major categories of vocabulary proposals. | ||
| + | |||
| + | ==Value Set Naming== | ||
| + | Discussion of externally defined Value Sets led to the discussion of the OID registry expectation for uniqueness of Value Set Names that are proposed in Harmonization. Specifically: | ||
| + | :Value Set Name uniqueness is imposed on value sets that are managed through Harmonization and which sit under OID Branch 2.16.840.1.113883.1.11....). This is true because the OID identifier rules require that the secondary identifier of an object must be unique for all objects directly under a single OID node, '''and''' within the OID registry, the Value Set Name is the secondary identifier of a value set, while the primary identifier is the OID itself. | ||
| + | |||
| + | ==Eliminating Duplicate Print Names== | ||
| + | Woody agreed to provide Wendy with the specific harmonization proposals that used names like "disease program", "healthcare operations", and "program reporting". | ||
| + | |||
| + | ==Correcting markup Errors in Descriptions== | ||
| + | Proponents '''must avoid doing copy/paste from Microsoft Word''' into proposals. This inevitably introduces elements like right- and left- quotes and right- and left- single quotes that produce unrecognizable content when entered into the data base. Further, requests to correct such entries '''must identify each place in which the error arises''' because the individuals updating the data base cannot reasonably be expected to find such instances. | ||
| + | |||
| + | ==Security Proposals== | ||
| + | Ted and Russ have been in contact with the proponent of the three Security proposals and will advise her on necessary changes for the final submissions | ||
==Adjournment== | ==Adjournment== | ||
| + | The meeting adjourned after one hour. | ||
Latest revision as of 01:25, 29 June 2012
Harmonization Technical Review Conference Call 10:30AM Eastern Time (Date above)
Agenda
- Review Proposals for July 2012 Harmonization
Attendees
Beeler, Shakir, Klein, Huang
Items Seeking Changes to the RIM During Second Trimester
The proposal set included one item that sought to make changes in the ActClass code hierarchy, and might have included another proposal (that was not formally submitted by the deadline) to change the ActRelationshipType codes. This led to the discussion of MnM's intent to limit RIM changes (including changes to the code systems that are referenced by RIM attributes typed with data type CS) to only those changes needed to reconcile negative votes arising from the annual May Ballot cycle RIM Normative ballot. Although this proscription has been in place for several years, it is not well documented.
The group agreed that this should be clearly documented on the Wiki and expressly listed in the Vocabulary and RIM Harmonization Process page. Along with these minutes, changes were made to the Harmonization Initial Proposal Rules and to the Wiki documentation of RIM Maintenance procedures.
Incomplete Documentation of Code System Changes
Discussion of proposal item "2012.PC.RS02" to "move" the "concern" (CONC) ActClass code within the hierarchy noted that although the proposal was understandable, it was not well enough documented that it could be interpreted unambiguously. It was noted that this proposal had, as have others in the past, used the Vocabulary Check List that is part of the harmonization template as a means to document intended content.
The group wishes to emphasize that the check list is intended solely as an aide memoire for the proponent and that each element in the list should result in an "entry" in the documentation of the desired changes.
In the proposal cited here, there should have been a detailed documentation of all data elements for the change including:
- Identification of the Code System that is involved by name, and (preferably) by code system OID
- Identify each code being deprecated, by code, and provide a rationale for the deprecation. This rationale should include recommendations for how users of the deprecated element should represent their content in the future.
- In this instance, the equivalent concepts for a set of codes was being "moved" by deprecating the prior coded concept and replacing it with a new code that has similar semantics. For each of the new codes the proposal should include:
- A new coded concept including its print name and definition;
- The new print names should differ from the old in order that searches will distinguish them
- Designation of the "parent" coded concept under which these codes will be placed in the hierarchy;
- Because these are ActClass codes there needs to be a specification of the Name:Class property of the codes. (In this case they can be the same as that assigned to the codes that are being replaced.)
- Because these codes are part of a "class code" or "type code" hierarchy a values set should be defined that includes this code and all of its future children, and whose name is ActClassPrintName. The name is a pro forma construct using the code system name concatenated with an upper-camel-case representation of the print name for the code.
- A new coded concept including its print name and definition;
The harmonization team agreed that we need to incorporate detailed instructions like this for all the major categories of vocabulary proposals.
Value Set Naming
Discussion of externally defined Value Sets led to the discussion of the OID registry expectation for uniqueness of Value Set Names that are proposed in Harmonization. Specifically:
- Value Set Name uniqueness is imposed on value sets that are managed through Harmonization and which sit under OID Branch 2.16.840.1.113883.1.11....). This is true because the OID identifier rules require that the secondary identifier of an object must be unique for all objects directly under a single OID node, and within the OID registry, the Value Set Name is the secondary identifier of a value set, while the primary identifier is the OID itself.
Eliminating Duplicate Print Names
Woody agreed to provide Wendy with the specific harmonization proposals that used names like "disease program", "healthcare operations", and "program reporting".
Correcting markup Errors in Descriptions
Proponents must avoid doing copy/paste from Microsoft Word into proposals. This inevitably introduces elements like right- and left- quotes and right- and left- single quotes that produce unrecognizable content when entered into the data base. Further, requests to correct such entries must identify each place in which the error arises because the individuals updating the data base cannot reasonably be expected to find such instances.
Security Proposals
Ted and Russ have been in contact with the proponent of the three Security proposals and will advise her on necessary changes for the final submissions
Adjournment
The meeting adjourned after one hour.
