LRI+Architecture+&+IR+WG+Meeting+Minutes+2011-5-9

include component="page" wikiName="siframework" page="LRI Header" =Architecture/Implementation Requirements WG Meeting Minutes=
 * Date:** 05/09/2011
 * Time:** 2:00 PM-3:00 PM EDT
 * Dial in:**1-408-600-3600 **Passcode:** 669 559 222
 * Meeting Agenda: LRI Arch & IR Agenda 05092011**

Attendance
Rob Allen, Nagesh (Dragon) Bashyam, Tom Boal, Amy Brantley, Kathryn Calderone, Joan DuHaime, Hal Jiang, Lester Keepper, Cynthia Levy, Bob Lutolf, Erik Pupo, John Ritter, Andriy Selivonenko, Rob Snelick, Jonathan Tadese, Serafina Versaggi, Steve Wagner, Bob Yencha

Action Items

 * **#** || **Date Initiated** || **Action** || **Owner** || **Status** || **Date Closed** ||
 * 1 || 05/09/2011 || Combine two draft abstract models into one common model and post to the wiki. || Cindy Levy/Rob Allen || Open ||  ||
 * 2 || 05/09/2011 || Review and comment on draft abstract models. || All || Open ||  ||
 * 4 || 05/09/2011 || Clarify the use case and determine which certification agencies apply. || All || Open ||  ||

Agenda Items
1. Confirm WG consensus and operating procedures. 2. Review 5/2/2011 Action Items 3. Review results of search for existing related deployment models. 4. Review Draft Abstract Model 5. Review Draft LRI Deployment Models and Applicability Spreadsheet 6. Continue Policy/Service Identification -Should Security Policies be included? 7. Discuss TOC Architecture Group work applicability to LRI -OMG -ToC Architecture Overview
 * Additional deployment models to consider - **participants to provide links/files**
 * Requesting clarification on primary care provider - Should terminology be changed to authorized provider to support travel requirements? **-** forward to use case team for review and disposition
 * Begin draft of abstract model - **WG Leads and Support Team to work together**
 * Ensure that cardinality makes clear sense - use of terminology among and between

Meeting Notes
We will use the abstract model as an example in attaining WG consensus.

The Leads went down the list of action items from last week’s meeting and discussed progress.

As far as requesting clarification on primary care providers from the use case team, the use cases are close to final consensus, so that is going to remain in the parking lot for now, and we will keep the terminology the same.

In finding out if there are any existing deployment models that this group could leverage, the Leads were directed to Bob Yencha for HITSP and Glen Moy for ELINCS. The information they provided can be found in the reference materials table on the wiki, under the entries dated 05/08/2011. Unfortunately, there were no deployment models that they could find. A question was asked whether reference implementation is something we should be focused on, as it may have been on Jira as an artifact but was not migrated to wikispaces. Reference implementation is actually not being done by either ToC or LRI, as it is a separate phase within the S&I Framework.

Cindy Levy and Rob Allen created draft abstract models that will be posted on the wiki. Members should plan to comment on those on the wiki this week, and we can vote next week (contingent upon having no updates from other products).

What is an abstract model & why are we doing it? The purpose of an abstract model is to get as high-level a view as possible in terms of what the critical transactions and data are. The first abstract model, created by Rob Allen, used the ToC abstract as a basis and reflects what was in the use case.

A key difference between the two abstract models is that Rob Allen tried to keep the specific terminology, roles, and functional requirements from the use case and allocated them to each of the two systems. Specific interactions are addressed at the bottom of the document.

Part of the goal is to come up with a “conceptual design”, and the abstract model is a key piece of that. It would be passed on to the reference implementation WG (Lockheed Martin) to develop working code.

The second abstract model, created by Cindy Levy, is an attempt to be consistent with discussion from ToC as well. The blue data are pre-conditions, required to receive manually or electronically (which is out of scope for the use case group). The lab results interface is on the right side and is also pulled from the use case. The source is creates a laboratory interface message and provides this information to the consumer, who receives, deciphers, and validates the message.

Rob Allen & Cindy Levy will work together to combine their two models into one common model and post it on the wiki. Workgroup members should review and comment on them during the week. It was asked whether the model should be bidirectional and unidirectional, with the response being bidirectional because there are confirmations coming back. With regards to terminology, because the use case team used the term “test results report”, this WG should use that term as well, as the consumer is not receiving raw data but rather a report on that data. A vote on the model will be held next week, dependent on a “re-look” when the implementation guide analysis is completed.

Regarding the two green boxes at the bottom of the model, what does “certified” entail? Are laboratory interface systems exempt from ONC certification? We need to indicate what certification is required, even if it is out of scope. There are different certification agencies for EHR and LIS – we should clarify the use case and determine which certification agencies apply. Use case talks about “certified EHR” but does not reference specific certification agency. Perhaps we should include a footnote indicating that certification is for the relevant authoritative body.

A method of commenting on the artifacts will be set up on the wiki, and members should add their comments throughout the week.

Next Meeting

 * Date:** 05/16/2011
 * Time:** 2:00 PM-3:00 PM EDT
 * Dial in:**1-408-600-3600 **Passcode:** 667 213 308

Reference Materials
1. Draft LRI Deployment Models and 2. Draft Abstract Model

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