6-6+LRI+Architecture+Notes

include component="page" wikiName="siframework" page="LRI Header" =Architecture/Implementation Requirements WG Meeting Minutes=
 * Date:** 06/06/2011
 * Time:** 2:00 PM-3:00 PM EDT
 * Dial in:**1-408-600-3600 **Passcode:** 666 372 808
 * Meeting Agenda:** 06/06 Agenda

Attendance
Rob Allen, Nagesh (Dragon) Bashyam, Tom Boal, Kathryn Calderone, Lester Keepper, Ed Larsen, Cynthia Levy, Cheryl Liu, Bob Lutolf, Ken McCaslin, Natalie Menser, Nam Nguyen, Tim Reardon, John Stinn, Jeff Tunkel, Merideth Vida, Kathy Walsh, Bob Yencha

Action Items

 * **#** || **Date Initiated** || **Action** || **Owner** || **Status** || **Date Closed** ||
 * 1 || 06/06/2011 || Review Architecture Overview and Implications and provide comments for discussion. || All || Open ||  ||
 * 2 || 06/06/2011 || Review Policy and Service Identification for discussion in the next meeting. || All || Open ||  ||

Agenda Items

 * 1) Review list of Policy & Service Identification
 * 2) Review Architecture Overview and Implications
 * 3) Review Policies for Validating Regulatory Conformance

Meeting Notes
The group went over RI Architecture Overview file that Cindy Levy put together. This overview is meant for discussion, and does not have all of Bob Lutolf’s comments. Will need to modify, but it’s a good start to cover. It captures a user story from a high level. We talked about what the RI implementation should be doing such as the validation of semantics and syntax, and the messages that are produced. The other part discussed is validation on various coding systems. This was mentioned on various levels. When you have standardized formats they ended up with some case pick list, units, values, large list of coded and other cases, text. Next, the group moved on to the next topic of the RI Architecture Overview file: ‘**Based** **upon the LRI User Story, what is In-Scope and out of scope’. **The group went through each item one by one.

> Part of what is being done is trying to take tests that are known, we will take test results for those known tests and create a catalog so we will know this is a valid result for these kinds of test. But we can’t do it for every department or every test. Sometimes patients have radical values that are off the charts and not within range of what we expect. If we tried to reduce volume in blood, so we will have a report saying patient is way off the charts for what we are testing. But lab results, 90% of time consistent and reliable, the other not consistent with what you expect. > Bob Lutolf-“ This idea of minimally reduced message content, Rob (Allen) do you remember discussions and what this means?” > Rob- “Implementation guide is highlighted on what segments is required. We go in and indicate, that if you are required you have multiple or just one. So that what you use is coming out of the Implementation Guide work group. When you get into segments, the message forms in message. We say this group, if you do have this group you minimally must have this segment included”. > > Cindy Levy-“I think it’s good to include in IR imp would be that you could further put in info states may require. We should foreshadow out of scope stuff like public health just in case we need to include it later”. > Cindy Levy-“ Validation of the range not reasonable because tests come back and the range sometime is purposely blown. Just because something is numeric, it may in fact not be numeric. It limits validation. > > Bob Lutolf- “The RI guide will not identify risk if tests go past range. We should address that the output of vocab group and ig group, may not be covered by those group and should be out of scope of the RI Implementation”. > > Cindy Levy- “We should put a discussion on some of these limitations. Some things happen are that the Knowledge base Ken provides may not be available so people may try to do this validation and realize it fails. I would like to make sure somewhere we document this. This info is important as to what you can do”.One of the drisks of us doing this in parallel (with other work groups) is there is some dependencies on those work groups. As we build whole product, there may be inconsistencies in what some of the groups talk about. There may need to be harmonization of harmonization.” > Cindy- If report is prelim as opposed to final, are there fields in report that are different or is it purely a status? > Preliminary report will come out, final may or may not change something in OBX5. Then again it may. Final may have different results from a preliminary report.
 * 1) **(Validation of Standardized data element formats)**
 * 1) **(Validation of minimally required message content )**
 * 1) **(Validation of Numeric from Test Results)**
 * 1) **Skipped. Already discussed.**
 * 2) **(How do we validate the Test Results Status? - preliminary, final, amended, corrected).**

Next discussion is on what is out of scope :

> Cindy Levy – “Discussion of potential RI Implementation is “taking an ELINCS implementation and transform into S&I message”. Cindy Levy- “At the time we were having the discussion saying this scope would be validation and not that creation. Now it’s changed so I will change that. I will make this step out of scope needs to be included if we are including transformation”. Some tests are numeric some are alpha, so u can’t take alpha and make it numeric. Some has ranges, some doesn’t. We should take this out completely.
 * 1) **Display in readable format sections from Test Results – Numeric; Textual Data, Test results in fixed format (OBX3-OBX8), blobs.**Cindy Levy- “I pulled out LRI User Stories that were important for the group. These are out of scope, but the RI group should know for the future.”
 * 2) **Creation of Standardized structured data-**
 * 1) **Creation of minimally Required Message Segment Content.**
 * 1) **Creation of Numeric from Test Results (Units and Range)**

Continue looking at Architecture implementation overview. Plan for next time at face to face- to go back to look at this..but we have other products I want to start tracking. Theres an Architecture Overview Implementation and Implications file. We are going to look at it before the next meetings, so view and add comments, and then we head into the Policy and Services file which Rob put together.

Next Meeting
Our regularly scheduled meeting on Monday June 13th will not occur. Instead, discussion will take place the 14th and 15th at the F2F meeting.

Reference Materials
1. RI Architecture Overview 2. Architecture Overview and Implications 3. Policy and Service Identification

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