MnM Minutes CC 20100603

M&M Ballot Reconciliation Conference Call 4:00 PM Eastern Time (Date above)

Logistics

Join GoToMeeting at

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

Meeting ID: 701-832-453

Agenda - RIM Ballot Reconciliation

Working document

The working document is the reconciliation spreadsheet posted on HL7 Ballot Desktop. Items are collected by the entries on the "Comment Grouping" column.

Comment Grouping "Disambiguate Quantity Attributes"

Items submitted by Christof Gessner of HL7 Germany. Review will be dependent on his ability to join call. All items relate to the definitions and relationships between the "quantity" attributes in Participation, Role and Entity. Covers five line items:

• Item 19 [No action Result combined in item 20]
• Item 20 (Christoph/Austin)

  Discussion:

  See additional detailed discussion from C. Gessner

  Note from G Grieve: Been looking at Christof's RIM comments, and chatting to him. The short answer is that we are in a solid mess on this subject I find his issues quite persuasive, though much more analysis is needed but {and?] there is no quick fix.

  I think that we should respond by acknowledging that this is a big deal, and creating a project that is tasked to find a resolution for future use - not just in the RIM, but policy as well.

  I will attempt to be on the call knowing that we moved it for me but it's 6am, I get home after midnight after 3 days on the road. So we'll see

  Note from A Kreisler: I'm reviewing as requested. One thing I do want to note, at one time I had to prove the assertion that "1" is a legal UCUM unit of measure, and at first couldn't find it listed as a code. It's not listed as an atom in UCUM, rather it comes from the syntax defined to be used along side the codes. In the syntax, any set of digits may legally be used in place of one of the atom codes. The UCUM standard document states that "1" is the default unit in several places, and it is inherent in the UCUM syntax, but it never appears as a "code".

• Item 21 [No action Result combined in item 20]
• Item 22 (Christoph/Gunther)

  Discussion:

• Item 23 (Christoph/Gunther)

  Discussion:

Comment Groupings "TechCorr" and "Error"

Items are Technical Corrections or other Errors discovered in RIM content. Covers six line items:

• Item 2 (Gunther/Jean)

  Discussion:

• Item 3 (Gunther/Jean)

  Discussion:

• Item 4 (Gunther/Jean)

  Discussion:

• Item 5 (Lloyd/Gunther)

  Discussion:

• Item 6 (Lloyd/Gunther)

  Discussion:

Comment Grouping "Correct"

Items wre balloted Neg-Mi and offer wording changes to correct meaning and/or other "corrections." Recommendation on all of these is Persuasive or Persuasive with Mod. Covers six line items:

• Item 7 (moved/seconded)

  Discussion:

• Item 13 (moved/seconded)

  Discussion:

• Item 15 (moved/seconded)

  Discussion:

• Item 24 (moved/seconded)

  Discussion:

• Item 27 (moved/seconded)

  Discussion:

• Item 28 (moved/seconded)

  Discussion:

Comment Groupings "RecordStatus", "ContextCond" and "Uncertainty"

Items submitted by Gunther Schadow. Covers five items:

• Item 30 (RecordStatus) (moved/seconded)

  Discussion:

• Item 31 (RecordStatus) (moved/seconded)

  Discussion:

  • Note from Kreisler

    Austin: I recall we did have this discussion when this new attribute was introduced. I agree with Gunther that the scope of thye attribute should apply beyond DEF and CRIT.

    It should be noted that the new recordStatusCode attribute already has obsolte and nllifed as status, since it uses the same state machine as statusCode. I thought at the time the introduction of this attribute was going to impact the statemachine used for statusCode, particularly nullify and obsolete. It looks to me like the statusCodwe would need to be restricted to ""Normal"" states while the recordStatusCode uses the full statemachine.

    I also think there are some major backward compatibi8lity problems that will be introduced by removing these two states from statusCode, since we have normative content (trigger events) mapped onto these two states.

• Item 32 (RecordStatus) (moved/seconded)

  Discussion:

  • Note from Kreisler

    Gunther seems to be arguing to both complete the work we started, and dumping it because we won't solve the overall problem using this approach.

    I certainly understand where Gunther is coming from on points 2&3, we have not solved the larger problem, but we have solved what we needed to handle eMeasure. Gunthers point is that the larger problem is that we may need to construct queries that now require using this meta-data as part of the query, and representing that in the RIM means we know need another level of indirection.

    I think this is going to require futher discussion and thinking. We still need to solve the problem for eMeasure, but we also need to solve the more general problem Gunther identifies. I'm just not certain what that solution needs to be.

  • Note from McKenzie

    For the recordStatus ones, I think Gunther is correct. We're going the wrong way with this solution. We've got an attribute that is only relevant for a couple of moods (which is a big no-no), we've got information that exists in two different places depending on what the mood is, and we've nearly doubled the number of mood codes by adding a whole whack of criterion ones.

    I did a bit of thinking and have run my ideas past Grahame. I think the solution is to drop the recordStatus attribute and deprecate *all* of the criterion moods. Instead, we should add a new boolean to Act called "isCriterion". If true, then *all* of the attributes and associations hanging off that Act behave as criteria. So you can use the mood, the authorship, even the characteristics of the Act.id attribute as criteria. To meet the need to be able to capture metadata about the Criterion act, we would introduce a special ActRelationship typeCode. It would be the *only* relationship which would not act as a criteria and would point to an Act whose attributes represent the characteristics of the criteria (identifier, authorship, type, effectiveTime, etc.)

    I think this approach provides a number of benefits:

    • It eliminates the issues I described above
    • It's backward compatible (the new boolean would have a default of false)
    • It permits criteria and metadata that the current solution does not.

    If you & Gunther are ok with the approach, I'll post a detailed proposal to the list.

• Item 33 (ContextCond) (moved/seconded)

  Discussion:

  • Note from McKenzie

    The difficulty has been minimized for future applications. In the near term, the difficulty has indeed increased, but there is no other way to reasonably manage the transition. We can't update all models simultaneously, thus there is the potential for different models to use different context conduction mechanisms. The attribute was added because there is no other means of differentiating between circumstances where context conduction is totally undeclared, and where context conduction is intended to flow according to the defaults of the new rules. The absence of all context conduction attributes could indicate either. In theory, specifying a property in the static model MIF files could work, but suffers from two issues:

    • Some applications attempt to parse v3 instances without the source MIF files
    • Some applications process based on schemas rather than MIFs

    The decision then is whether the cost of the attribute is worth the grief it will cause those types of applications. We could go either way here and will need to discuss in committee which is most appropriate.

• Item 34 (moved/seconded)

  Discussion: