This wiki has undergone a migration to Confluence found Here
Difference between revisions of "MnM Minutes Harmonization CC 20120216"
Jump to navigation
Jump to search
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[Category:2012 MnM Minutes]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
__NOTOC__ | __NOTOC__ | ||
| − | =M&M Harmonization Technical Review | + | =M&M Harmonization Technical Review Call (Date above)= |
| − | |||
[[:Category:2012 MnM Minutes|Return to MnM Minutes]] | [[:Category:2012 MnM Minutes|Return to MnM Minutes]] | ||
==Agenda== | ==Agenda== | ||
| Line 16: | Line 9: | ||
==Items Submitted but "Blocked" by Site Policies== | ==Items Submitted but "Blocked" by Site Policies== | ||
| − | At the outset, we discussed a number of proposals from legitimate sources that could not be posted because the submitter was not a Co-chair of one of the participating committees. We agreed to accept | + | At the outset, we discussed a number of proposals from legitimate sources that could not be posted because the submitter was not a Co-chair of one of the participating committees. We agreed to accept five such proposals that were put forward on the Harmonization list within days of the deadline. |
ACTION ITEM: Agreed to seek means by which any Modeling or Vocabulary Facilitator has privileges to submit Harmonization Proposals, not just Co-chairs. | ACTION ITEM: Agreed to seek means by which any Modeling or Vocabulary Facilitator has privileges to submit Harmonization Proposals, not just Co-chairs. | ||
| Line 28: | Line 21: | ||
Discussed the issues noted in the pre-technical review report on three items submitted on behalf of the Security Work Group. There are two sets of issues with these proposals. | Discussed the issues noted in the pre-technical review report on three items submitted on behalf of the Security Work Group. There are two sets of issues with these proposals. | ||
===Proposed Content Cannot be Interpreted=== | ===Proposed Content Cannot be Interpreted=== | ||
| − | The material presented makes it '''very difficult''' to discern what is to be changed and how. Similar concerns arose in the November 2011 submissions from the same work group | + | The material presented makes it '''very difficult''' to discern what is to be changed and how. Similar concerns arose in the November 2011 submissions from the same work group. In that cycle, the finalization of the Security proposals took over 70% of the effort spent on the entire package, despite that they were but two of 27 proposals reviewed. |
The primary concern is reflected in the Technical review note that said: | The primary concern is reflected in the Technical review note that said: | ||
| Line 35: | Line 28: | ||
:This whole thing needs to be separated into (1) Concept Domain Adds, Moves, & Changes.(2) Code System and code Adds, moves, changes. (3) Value Set Adds, moves, changes. (including which codes from which code systems are in the Value set. and (4) Context Bindings of Concept Domains to Value sets. | :This whole thing needs to be separated into (1) Concept Domain Adds, Moves, & Changes.(2) Code System and code Adds, moves, changes. (3) Value Set Adds, moves, changes. (including which codes from which code systems are in the Value set. and (4) Context Bindings of Concept Domains to Value sets. | ||
| − | The | + | The reviewers agreed unanimously that these proposals '''must be re-structured if they are to be reviewed in March'''. There are two sets of requirements for this restructuring that are considered '''mandatory''': |
| − | #Separate each set of changes into tables that | + | #Separate each set of changes into tables that reflect only the Vocabulary element being changed. (Suggest that the editor review the tables used to publish Vocabulary content in current HL7 Ballots.) Specifically: |
#: | #: | ||
| − | #* One (or more) tables listing '''only''' Concept Domain additions or changes, with column headings for Type of change ( | + | #* One (or more) tables listing '''only''' Concept Domain additions or changes, with column headings for at least - Type of change ('''A'''dd, '''M'''ove or '''C'''hange), ParentConceptDomainName, ConceptDomainName, Definition, Other Annotations, Examples, and so on. |
#*: | #*: | ||
| − | #* One (or more) tables for '''each Code System''' in which changes are being made. Column headings | + | #* One (or more) tables for '''each Code System''' in which changes are being made. Column headings for at least - Type of change ('''A'''dd, '''M'''ove or '''C'''hange), CodeSystemName, ParentCode, Code, PrintName, Definition, Other Annotations, and so on. |
#*: | #*: | ||
| − | #* One (or more) tables for Value Set additions and changes. Column headings | + | #* One (or more) tables for Value Set additions and changes. Column headings for at least - Type of change ('''A'''dd, '''M'''ove or '''C'''hange); ValueSetName; Description of Value Set; Other Annotations; CodeSyetemName from which Codes are drawn; Code; Indicator of whether single code is added with this line, or whether it is the code and all its children; and so on. |
#: | #: | ||
| − | #* One (or more) tables listing '''only''' Context Bindings of Concept Domains to Value Sets. Column headings for Type of change ( | + | #* One (or more) tables listing '''only''' Context Bindings of Concept Domains to Value Sets. Column headings for at least - Type of change ('''A'''dd, '''M'''ove or '''C'''hange), ConceptDomainName, ValueSetName, Binding Realm. |
# Use '''only the annotation types prescribed in the MIF'''. The material from November and this cycle include both "definitions" and "descriptions" whereas the MIF provides for '''definitions on Concept Domain and Coded concept''' and '''descriptions on Code Systems and Value Sets'''. If Security feels the codes need further annotation than the definition on Codes and Concept Domains, they should select one of the other annotation forms in the MIF (see lists below) or propose a MIF change (on Gforge) to extend the annotation types. | # Use '''only the annotation types prescribed in the MIF'''. The material from November and this cycle include both "definitions" and "descriptions" whereas the MIF provides for '''definitions on Concept Domain and Coded concept''' and '''descriptions on Code Systems and Value Sets'''. If Security feels the codes need further annotation than the definition on Codes and Concept Domains, they should select one of the other annotation forms in the MIF (see lists below) or propose a MIF change (on Gforge) to extend the annotation types. | ||
| − | The '''valid annotation types for each type of artifact'' are in the following table, where CD=ConceptDomain; CC=CodedConcept; CS=CodeSystem; and VS=ValueSet. | + | :The '''valid annotation types for each type of artifact''' are in the following table, where CD=ConceptDomain; CC=CodedConcept; CS=CodeSystem; and VS=ValueSet. |
{|width=65% cellspacing=0 cellpadding=2 border=1 | {|width=65% cellspacing=0 cellpadding=2 border=1 | ||
| Line 182: | Line 175: | ||
:"Submission approved, but WG wants to review again before final approval"? | :"Submission approved, but WG wants to review again before final approval"? | ||
| − | If this means that the Security Work Group needs to review the Harmonization Results before they are applied to the data base, it is '''very likely''' that the content will not appear in the immediately following ballot. HL7 funds the process of finalization of vocabulary content, but this must be completed before the ballot opens - about two seeks after Harmonization. | + | If this means that the Security Work Group needs to review the Harmonization Results before they are applied to the data base, it is '''very likely''' that the content will not appear in the immediately following ballot. HL7 funds the process of finalization of vocabulary content, but this must be completed before the ballot opens - about two seeks after Harmonization. This schedule does not permit of a separate review between the end of the meeting and the posting. |
| − | The whole premise of Harmonization is that the Work | + | The whole premise of Harmonization is that the Work Groups grant to their voter the right to accept changes proposed during the meeting. Perhaps Security Work Group should have one or two co-chairs in attendance rather than seeking to "iterate" the definitions. |
==Adjournment== | ==Adjournment== | ||
Meeting adjourned after 60 minutes | Meeting adjourned after 60 minutes | ||
Latest revision as of 19:24, 15 March 2012
M&M Harmonization Technical Review Call (Date above)
Agenda
- Perform Technical Review on Contents of Harmonization Preview Package
Attendees
Beeler, McKenzie, Hamm, Klein, Huang, Glover
Items Submitted but "Blocked" by Site Policies
At the outset, we discussed a number of proposals from legitimate sources that could not be posted because the submitter was not a Co-chair of one of the participating committees. We agreed to accept five such proposals that were put forward on the Harmonization list within days of the deadline.
ACTION ITEM: Agreed to seek means by which any Modeling or Vocabulary Facilitator has privileges to submit Harmonization Proposals, not just Co-chairs.
General Item Review Concerns
Reviewed a number of proposals and discussed issues with display of properties in RoseTree and Ballot.
ACTION ITEM: Beeler to assure that all Concept Domain properties are expressed in both RoseTree and Ballot expressions.
Proposals from Security Work Group
Discussed the issues noted in the pre-technical review report on three items submitted on behalf of the Security Work Group. There are two sets of issues with these proposals.
Proposed Content Cannot be Interpreted
The material presented makes it very difficult to discern what is to be changed and how. Similar concerns arose in the November 2011 submissions from the same work group. In that cycle, the finalization of the Security proposals took over 70% of the effort spent on the entire package, despite that they were but two of 27 proposals reviewed.
The primary concern is reflected in the Technical review note that said:
- Uninterpretable. WHERE do the tabular displays come from. They are NOT from the standard way of publishing in HL7 ballots today. They look like ancient vestiges from before May 2008. They are very difficult to interpret because they conflate Concept Domains, Code Systems and Value sets.
- For example, the recommendation says "Associated code system should be named 'HealthInformationPurposeOfUse', but there is no associated code system. I suspect you are talking about an abstract head code in either ActReason or ActCode, but cannot determine which.
- This whole thing needs to be separated into (1) Concept Domain Adds, Moves, & Changes.(2) Code System and code Adds, moves, changes. (3) Value Set Adds, moves, changes. (including which codes from which code systems are in the Value set. and (4) Context Bindings of Concept Domains to Value sets.
The reviewers agreed unanimously that these proposals must be re-structured if they are to be reviewed in March. There are two sets of requirements for this restructuring that are considered mandatory:
- Separate each set of changes into tables that reflect only the Vocabulary element being changed. (Suggest that the editor review the tables used to publish Vocabulary content in current HL7 Ballots.) Specifically:
- One (or more) tables listing only Concept Domain additions or changes, with column headings for at least - Type of change (Add, Move or Change), ParentConceptDomainName, ConceptDomainName, Definition, Other Annotations, Examples, and so on.
- One (or more) tables for each Code System in which changes are being made. Column headings for at least - Type of change (Add, Move or Change), CodeSystemName, ParentCode, Code, PrintName, Definition, Other Annotations, and so on.
- One (or more) tables for Value Set additions and changes. Column headings for at least - Type of change (Add, Move or Change); ValueSetName; Description of Value Set; Other Annotations; CodeSyetemName from which Codes are drawn; Code; Indicator of whether single code is added with this line, or whether it is the code and all its children; and so on.
- One (or more) tables listing only Context Bindings of Concept Domains to Value Sets. Column headings for at least - Type of change (Add, Move or Change), ConceptDomainName, ValueSetName, Binding Realm.
- One (or more) tables listing only Concept Domain additions or changes, with column headings for at least - Type of change (Add, Move or Change), ParentConceptDomainName, ConceptDomainName, Definition, Other Annotations, Examples, and so on.
- Use only the annotation types prescribed in the MIF. The material from November and this cycle include both "definitions" and "descriptions" whereas the MIF provides for definitions on Concept Domain and Coded concept and descriptions on Code Systems and Value Sets. If Security feels the codes need further annotation than the definition on Codes and Concept Domains, they should select one of the other annotation forms in the MIF (see lists below) or propose a MIF change (on Gforge) to extend the annotation types.
- The valid annotation types for each type of artifact are in the following table, where CD=ConceptDomain; CC=CodedConcept; CS=CodeSystem; and VS=ValueSet.
| CD | CS | CC | VS | Annotation/Properties/Other |
| x | x | Description | ||
| ** | ** | Definition | ||
| x | x | x | x | UsageConstraint |
| x | x | x | x | UsageNotes |
| x | x | x | x | Rationale (why needed) (uncommon) |
| x | x | x | x | Requirements (uncommon) |
| x | x | x | x | DesignComments (uncommon) |
| x | x | x | x | StabilityRemarks (uncommon) |
| x | x | x | x | OpenIssue |
| x | x | x | x | DeprecationInfo |
| ** | Based-on CodeSystem (Code System name) | |||
| x | Parent Concept Code | |||
| x | Parent Concept Domain | |||
| ** | Examples (list) | |||
| x | isImmutable (Boolean property) | |||
| x | isSelectable (Boolean property) | |||
| x | conceptualSpaceForClassCode (String property) |
Meaning of "Approval by Sponsor" Notation
What does it mean in these proposals, where the "Approval by Sponsor" field bears the notation:
- "Submission approved, but WG wants to review again before final approval"?
If this means that the Security Work Group needs to review the Harmonization Results before they are applied to the data base, it is very likely that the content will not appear in the immediately following ballot. HL7 funds the process of finalization of vocabulary content, but this must be completed before the ballot opens - about two seeks after Harmonization. This schedule does not permit of a separate review between the end of the meeting and the posting.
The whole premise of Harmonization is that the Work Groups grant to their voter the right to accept changes proposed during the meeting. Perhaps Security Work Group should have one or two co-chairs in attendance rather than seeking to "iterate" the definitions.
Adjournment
Meeting adjourned after 60 minutes
