This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

MnM Minutes CC 20080208

From HL7Wiki
Revision as of 01:46, 21 May 2010 by Gwbeeler (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

M&M Conference Call, February 8, 2008

Attendees

Lloyd McKenzie, Austin Kreisler, Abdul Malik Shakir, Woody Beeler, Sarah Ryan, Gregg Seppala, Craig Parker, Dale Nelson, Lee Coller, Jay Lyle, Grahame Grieve

Agenda Items

Approval of past minutes

Minutes from January 25 approved unopposed.

Techical Editing Project review of materials, as requested by Jay Lyle (25 min)

See V3_Technical_Editors_Project_Works_in_Progress

Motion (Jay/Lloyd) Adopt as MnM tasks the tasks listed in the RIM_Editorial_Tasks_080113.pdf document.

  • Motion passes (9:0:0)

RimDataDictionary_Eneity_example_080110.pdf

  • Line 4: Change "Attributes" to "Features".
  • Line 12: Make this a cleaner pattern.

Woody and Jay will work on the mechanics of making the editorial updates. They will publish a time for a meeting to discuss this for anyone who wants to participate.

Jay will work on the 6 core classes. He will have them ready for review by February 28th. We will discuss them on the March 7th conference call.

We will establish a strategy for moving forward during the April interim meeting.

Motion (Abdul Malik/Dale) Accept he plan as described above.

  • Motion passes (8:0:0)

Review and Approve Project Scope Statements for CMETs (Nelson) (15 min)

Review of "CMET R7 HL7 Project Scope Statement.doc" Change R7 to R8 Add RCRIM TC to the Project Dependencies list. Motion Dale AMS Forward this proposal to the steering division for adoption (8:0:0)

Motion (Dale AMS) Forward to HQ intent to ballot for

  • CMETs R8 for membership
  • CMETs R8 for committee
  • core principles
  • Motion passes (8:0:0)

Null Flavor Issue to Help resolve Data Types Ballot issue (Grieve) (10 min).

Grahame summarized the question by email as:

So this will be discussed on the MnM call due shortly. Woody asked me to make a draft motion to get things going.

Clearly there is quite a lot of scope for genuine work here, and I think that it's worth doing so. But we shouldn't rush this. So for now, we should focus on the immediate question, about what is the correct NullFlavor to use if a user does not provide an answer to an entry on some kind of form.

There appears to be three options for this case:

  • ASKU - asked but answer still pending
  • NA - not applicable in this context.
  • NI - no information

It seems to me that there's not much to say, and not much need to say anything - there's no answer. Who knows why? maybe the user was in a hurry, but what difference does it make? how would you process the information differently if you knew which of the various reasons that the user didn't fill the content in?

So it should simply be NI - there is no information, and we don't really have good information as to why.

There's a related issue - people seem to think that because there's a nullFlavor, it should be used, and that simply using NI is... improper. I don't see why.

I move the following motion:

 The the correct nullFlavor to use in this circumstance is NI, 
 and that the nullFlavor documentation in the new Core Properties 
 document should describe this use of NullFlavor

Motion (Grahame/Lee) as above.

  • Motion passes (7:0:0)

I also move:

 that MnM create an open hot topic, and put the content from 
 Dipak and Julie into the hot topic. We should start be making an 
 agreed mission statement for NullFlavor: what is nullFlavor actually 
 intended to achieve.

Motion (Grahame/Dale) as above.

  • Motion passes (7:0:0)

Other TBD

It was suggested that on the MnM Hot Topics call in 2 weeks that the committee discuss the relationship between harmonization and balloting.

Motion to adjourn.