LRI+IG+Analysis+WG+Meeting+2012-03-01

include component="page" wikiName="siframework" page="LRI Header"

LRI IG Analysis Meeting Minutes
 ** WebEx: ** **http://www.mymeetings.com/siemens/nc/join.php?i=741301183&p=&t=c**  ** Dial-In: ** ** 1-888-998-2663 **  ** Access Code: ** ** 2410512 **  ** WebEx Passcode: ** ** HL7OO **
 * __Thursday 3/1 2:00PM ET-4:00PM ET __**

**Meeting Agenda:**
Use Case Simplification WG ||
 * < **ID** ||< **Key Discussion Items** ||< **Duration** ||< **Presenter** ||
 * < 1 ||< Use Case WG Discussion:
 * [|Draft Simplification Alignment Overview]
 * [|Draft Simplification Alignment - LRI Assumptions, Pre/Post Conditions (Incomplete)] ||< 60 Minutes ||< Hans Buitendijk/
 * < 2 ||< Vocab WG Update
 * SPM.21 to SPM.24 ||< 10 Minutes ||< Riki Merrick ||
 * < 3 ||< Examples Discussion ||< 50 Minutes ||< Hans Buitendijk ||

Hans Buitendijk, Kris Cyr, Gary Dickinson, Freida Hall, Ron Hausam, Austin Kreisler, Kosta Makrodimitris, Ken McCaslin, Natalie Menser, Riki Merrick, Brian Pech, Scott Robertson, Rob Snelick, Shalina Wadhwani
 * Meeting Attendance: **

Action Items
//No action items at this time.//


 * Vocab WG Update **
 * Riki Merrick talked to Cindy Johns but they only got through the SPM.21 discussion
 * The Vocab WG is meeting again on Tuesday March 6th from 10:00 AM – 11:00 AM


 * Draft Simplification Alignment – LRI Assumptions, Pre/Post Conditions**
 * Gary – effort to review all of the Use Cases and identify the particular things found in common across use cases
 * Components identified can be registered in a spreadsheet repository
 * Freida Hall helped with a deep dive assessment looking at the data requirements coming out of LRI
 * These were mapped against the consolidated CDA
 * One thing looked at were core requirements documented in a Use Case catalog
 * Ex. TOC Use Case is being used in LCC
 * Group has been analyzing the work of the initiatives to find commonalities
 * Specially looking at the requirements aspect
 * Looked at the initial work coming out of the requirements phase of LRI and looked at the assumptions and pre/post conditions
 * Have identified 5 require types
 * P is policy
 * SF is system functionality
 * SC is systems configuration
 * SR is system at run-time
 * BR is business in real-time requirement
 * With a requirement type, they described who specifies it, when it is specified, and show applicability in terms of who and when it is applicable
 * This is a high-level way to look at requirements from a traceability standpoint
 * Ask of the LRI group is to look at the assumption and determine if it is pre, during, or post use case, then determine common requirements and common actions
 * Hans Buitendijk – assuming we all agree on the pre/post form, do we only fill in common requirements for post-conditions?
 * Gary – you still would fill out the requirement, but it would only be an SF requirement
 * Gary would like the IG Analysis group to confirm what is in in the 2nd and 3rd column, then determine whether it should be a core requirement, meaning, would it be applicable to a broader range of initiatives or used in future use cases?
 * Hans – how should the work be divided and what is the timeline?
 * Meredith – the expertise lies within the IG Analysis WG
 * We want to make sure we can re-use as much as we can from the past
 * Its beneficial to collaborate on the document
 * Austin – we shouldn’t address this in the next month because we have deadlines to meet. If its’ going to be done, it should be done after the balloting is complete
 * Kosta – we should think about how this can benefit S&I as a whole
 * The consensus is to address the document after LRI balloting is complete
 * Freida Hall – if there are some volunteers that are willing to work on the initial draft, we can use that document as the basis of review in the next 3-4 weeks
 * Figure out what joint sessions should be held in the next few weeks


 * Parent-Child**
 * Was discussed at the OO meeting
 * Proposal itself was discussed – is it backward compatible
 * The answer was that it is backwards compatible
 * Should we add a repeat on the Parent Field?
 * The action from OO was that we shouldn’t focus on it yet, because it opens up more questions
 * The proposal was put up for a motion, independent of whether it will go in 2.7.1 and the motion was accepted
 * Second part of the conversation was if we can put this in 2.7.1
 * The change is substantive and it happens in the second round of the ballot, so are we setting a precedent that may cause some ANCI challenges?
 * Austin is following up with individuals to see if procedurally, we can move it into v2.7.1 by re-opening the ballot pool, since it was not part of the first round of the ballot
 * The question is whether it falls under the scope of 2.7.1 as a new item
 * If it cannot go into 2.7.1 because of the procedural challenges, then we can’t include it until V2.9
 * Next Thursday in OO the appropriate direction will be given


 * Examples Discussion**
 * Examples of individual data types are useful
 * Riki has been helping create examples
 * Austin Kreisler – will take the sample micros he created for Section 6 and will populate the data in a template provided to come up with a set of examples
 * Hans – for the micro we get some information so once we get to parent child we have an example of what a large message looks like for a complicated case
 * Validation suite already has some examples
 * Individuals could provide example messages in the LRI Data Test Case Management spreadsheet and Rob Snelick would create the columns
 * Between Austin’s examples and the Validation Suite tables, there would be enough information to create examples for this ballot spreadsheet
 * The Pilots are also creating examples, so by the time it goes normative, there are enough examples
 * Materials on the Validation suite wiki from the CBC, Lipid panel, Sed Rates, Comprehensive Metabolic Panels, Cystic Fibrosis, Meta Hemolytic Strep, MRSA, etc would be documents that are used as the basis for these examples
 * Full message snipits, segment snipits, and data type snipits would be included
 * Austin Kreisler moves, Riki Merrick seconds; 0 against, 0 abstain, 10 for


 * Next Steps**
 * After Tuesday we will go through the ballot reconciliation spreadsheet and ensure all items are closed
 * Austin – it may be useful to include a spreadsheet that has OIDs for comments for people assignment CLIA number, NPI numbers, etc.
 * Comments for everyone using the GU profile would have to provide
 * Most of those are already registered with HL7
 * So we need to get rid of sample OIDs and use real OIDs
 * Austin – the purpose of having the sample OID is that it won’t interfere with sometime real. You need explanatory text saying that the OIDs are not real for that CLIA identifier
 * Statement that all OIDs except for those used in MSH21 are all sample OIDs


 * Section 6 Parent-Child Proposal – Austin Kreisler**
 * He added information from OBR.11 on specimen action codes, which was included in the original proposal
 * Added a table on component profile combinations
 * OBR.29 has not changed
 * Examples were updated so they confirm with the guide (strip out guides that are optional or not supported)
 * These examples will be put into the message maker by Rob Snelick to develop messages, which will then be used as examples
 * Nothing would change when putting this in V2.5.1 except for changing the name of the title
 * Will go through the information on Tuesday so the group is in agreement with all adjustments made before going into the IG
 * Tuesday will discuss Parent-Child, Vocab, and will give an update on Parent-Child 2.7.1, will go through ballot spreadsheet to look at red items

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"