MnM Minutes Harmonization CC 20120216

M&M Harmonization Technical Review Conference Call 4:00PM Eastern Time (Date above)

Logistics

Join GoToMeeting at

https://global.gotomeeting.com/join/701832453

Meeting ID: 701-832-453

Return to MnM Minutes

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 5-such proposals that were brought 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 to do the whole 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 review focused on two sets of requirements that will be considered mandatory if the material is to be reviewed in March:

1. Separate each set of changes into tables that are reflect the Vocabulary element being changed. (Suggest that 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 (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 include 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 include 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.
   • One (or more) tables listing only Context Bindings of Concept Domains to Value Sets. Column headings for Type of change (add, move or change), ConceptDomainName, ValueSetName, Binding Realm.
2. 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.

The whole premise of Harmonization is that the Work Group grants 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