PD+Sprint+Meeting+Session+8+Meeting+Minutes+2011-07-22

Date : //7/22/2011//

Name: //Provider Directories (PD) Initiative Sprint Team// Meeting //8//

Agenda/Objectives:

 * Topic || Time Allotted ||
 * Initiative Updates and Announcements || 10 minutes ||
 * Query for Electronic Address/Service Information Use Case || 100 minutes ||
 * Sprint Team Logistics/ Next Steps and Questions || 10 minutes ||

Attendees:
Aleena Dhar, Paul Cartland, Steve Tripp, Kelly Conlin, Peter Bachman, Ken Pool, Dave Shevlin, Dan Kearney, Don Jorgenson, Erik Pupo, Gail Kocher, Odysseas Pentakalos, Sasewata Ghose, Peter Gilbert, Michael Nelson, Chris Andreou, marcus clayton, Lester Keepper, Noam Arzt, Ron Sawdey, Ananya Gupta, Ernest Grove, Walter Suarez, rao parvatam Virginia Riehl, Roy Tharpe, david tao, Sri Koka, Margaret Weiker, McLain Causey, lin wan

Panelist Attendees:
Virginia Riehl and Victoria Njoku


 * Date || Description || Status || Notes ||
 * 7/22/11 || Review the full Use Case and provide comments using the discussion threads. || OPEN || Sprint Team Members ||
 * 7/22/11 || Address comments and make additional revisions during the 7/28 SWG and 7/29 Sprint Team meetings to complete the Use Case and present it for consensus || OPEN || SWG and Sprint Team Members ||
 * 7/22/11 || Update Charter and all applicable Wiki pages to reflect the change in scope, name of the Use Case, and new name of the sub-workgroup i.e. Electronic Service Information Discovery SWG || OPEN || Support Leads ||

Action Items:
=Use Case Content Discussion:=

Key Discussion Points:

 * Proposal to change scope and name of Use Case:
 * The proposal resulted from the discussion on data elements and realizing a need to provide a subset of information to help find the electronic address associated with a destination. This information appeared to be additional data elements associated with an electronic service
 * Given other service information could now be discovered, a question was raised whether the same query could be used downstream to probably get universal information about a provider or organization.
 * The clarification was it may be possible but the current Use Case just focuses on electronic addresses and now other service information for an endpoint
 * A question was raised whether a messaging framework was defined in the Use Case and the clarification was the Use Case does not define this. This work stream is only focused on defining the data elements and mapping to few standards, but not determining the messaging framework or standards
 * Two options for the name of the Use Case was presented i.e. //Query for Electronic Address and other Service Information// or //Query for Electronic Service Information including Electronic Address// and the group selected the latter
 * Definition of Electronic Service Information:
 * The draft definition proposed by Bob Dieterle influenced modifications to the data elements under the Electronic Service Information section in the return message table
 * A request was made to add a reference to the test or production environment. Including “Usage” as an additional data element addressed this Request
 * To align with the proposed definition, “Recipient name” seems to be a type of recipient information that can be returned, so “Recipient Information” should be used instead as a data element
 * The definition mentioned “Type of information (e.g. patient summary)” that a destination can receive from the sender and this was also noted as an additional data element to include
 * Under the Electronic Service Information section, the data elements captured at the same level except the //Unique Reference for Electronic Service Information// appears to be associated with the electronic address directly than the electronic service itself. These elements should be indented under the “Electronic Address” data element
 * Minor revisions were made to the draft definition: 1) excluding that “routing information (e.g. through an HIE)” is part of the information that can be returned because it is already captured under “the Messaging Framework supported (e.g. Direct, NwHIN Exchange),” 2) changing “security artifact” to “security information”
 * Revisions to Overview and Scope:
 * The in scope statements and successful outcomes of the Use Case appears broad and were revised to be more specific to the Use Case
 * This Use Case will not lead to a standardized query mechanism for Provider Directories or standardization and simplification of the implementation of interfaces to query Provider Directories in general, so it should not be included as successful outcomes
 * Given that the scope of the work stream is more focused on the core data elements to support queries to discover the electronic service information, there should be a specific outcome to reflect this
 * Developing interface specifications is not included in this work stream and should not be listed as in scope
 * The statement “//This Query for Electronic Address Use Case includes the capabilities of the Query for Digital Certificate Use Case for Direct Project by reference as required”// may need more clarification to external readers or could be eliminated if there was some other reference has been made in the alternate flow or diagrams
 * A suggestion was made to include some clarifying statements about how out of scope items will be addressed and by whom or when if possible.
 * Some of these items potentially pose certain risks or barriers to the Use Case and can be captured under the //Issues, Obstacles, and Potential Risks// section
 * Other out of scope items not addressed in this section would be included by the Support Leads and reviewed on the next call
 * The group agreed with the change in scope and no objections were made
 * The group selected “Query for Electronic Service Information including Electronic Address” as the name of the Use Case
 * The draft definition of Electronic Service Information was modified to be “A//ll information reasonably necessary to define an electronic destination’s ability to receive and consume a specific type of information (e.g. discharge summary, patient summary, laboratory report). The information should include the type of information (e.g. patient summary) the destination’s Electronic Address (see definition above), the Messaging Framework supported (e.g. Direct, NwHIN Exchange), Security information supported or required (e.g. digital certificate) and specific payload definitions (e.g. CCD C32 V2.5). In addition, this information may include specific recipient information (e.g. medical records department).”//
 * Revisions to the //Dataset Considerations//section are as follows:
 * “Usage” was added under the Electronic Service Information section in the return message table
 * “Recipient Information” was added and “Recipient name” was included as one of its example
 * “Type of information (e.g. patient summary)” that a destination can receive from the sender and this was added
 * The data elements captured at the same level with Electronic Address except the Unique Reference for Electronic Service Information elements were indented under the “Electronic Address” data element to show that they are associated with the electronic address directly than the electronic service itself
 * Revisions to the //Overview and Scope// section are as follows:

**Resolution(s):**
Outcomes specifying standardized query mechanism for Provider Directories or standardization and simplification of the implementation of interfaces to query Provider Directories were removed A new outcome was added: “//Core set of data elements to support queries to Provider Directories to retrieve Electronic Service Information including electronic addresses that can be adopted by EHR vendors, State HIEs, HISPs and other mediators of exchange”// The statement “//This Query for Electronic Address Use Case includes the capabilities of the Query for Digital Certificate Use Case for Direct Project by reference as required”// was removed
 * Revisions to the //Issues, Obstacles, and Potential Risks//section are as follows:
 * The statement “The lack of a transport mechanism, between the Electronic Service Information Consumer and the Electronic Service Information Provider, that will provide guaranteed delivery and error handling” was added
 * The statement “The absence of mechanisms for queries or Exchanges between Provider Directories themselves could limit the availability of Electronic Service Information and limit the ability of a the query to return a response with the requested information”

Key Discussion Points:

 * Next Certificate Discovery SWG Meeting rescheduled for **Monday** **July 25, 2:30-4:00PM ET**
 * Next Electronic Address/Service Information Discovery SWG Meeting scheduled for **Thursday July 28, 12:00-1:30PM ET)**
 * Next Sprint Team Meeting scheduled for **Friday July 29, 2011 3:00-5:00PM ET**
 * Home work Items:
 * 1) Sprint Team members should review the full Use Case and provide comments using the discussion threads.
 * 2) SWG and Sprint Team members will address comments and make additional revisions during the 7/28 SWG and 7/29 Sprint Team meetings to complete the Use Case and present it for consensus
 * 3) Support Leads will update the Charter and all applicable Wiki pages to reflect the change in scope, name of the Use Case, and new name of the sub-workgroup i.e. Electronic Service Information Discovery SWG