PD+Electronic+Service+Information+SWG+Meeting+Session+7


 * Date**: July 28, 2011 12:00-1:30PM EDT
 * Name**: Provider Directories (PD) Initiative – Electronic Service Information Discovery SWG Meeting Session 7

Agenda/Objectives:

 * **Topic** || **Time Allotted** ||
 * Revisions to //Query for Electronic Service Information including Electronic Address// Use Case || 80 minutes ||
 * Sprint Team Logistics/Next Steps || 10 minutes ||

rao parvatam, Tynisha Carter, Erik Pupo, Michael Nelson, Lester Keepper, Susan Campbell, Karen Witting, Jonathan Tadese, Robert Dieterle, mary-sara jones, Lin Wan, Ron Sawdey, Aleena Dhar, Dave Shevlin, JOHN MOEHRKE, Steve Tripp, Dan Huber, Ernest Grove, Dan Kearney, Kelly Conlin, Chris Andreou, Ananya Gupta
 * __Attendees:__**

__Panelist Attendees:__ Victoria Njoku


 * Action Items:**
 * **Date** || **Description** || **Status** || **Notes** ||
 * 7/28/11 || Review updated Use Case and provide comments on Wiki (if any) to be addressed during 7/29 Sprint Team meeting || OPEN || SWG and Sprint Members ||
 * 7/28/11 || Respond to posted topics/requests under the [|discussion threads]. || OPEN || SWG and Sprint Members ||


 * Revisions to** //Query for Electronic Service Information including Electronic Address// **Use Case**
 * //Key Discussion Points://**
 * Overview and Scope - Out of Scope, Background, Regulatory Issues, Communities of Interest, Challenge Statement, and Value Statement sections
 * No revisions were discussed and made
 * Overview and Scope - Policy Issues
 * The architecture to support Provider Directories and the maintenance of their data are out of scope for the Use Case, hence there was a debate whether to note both as policy issues
 * Policy issues identified are those that need to be addressed in order to realize the capabilities envisioned in the Use Case, hence including both architecture and maintenance seemed appropriate to keep
 * Indicating that a risk analysis related to unintended discoverability, privacy, and security must be conducted as part of harmonization seems out of scope for the work stream. Hence the statement was revised to clarify that Provider Directories need to have the capability to comply with policies regarding discoverability, privacy, and security
 * Use Case Assumptions
 * Some assumptions appear as requirements
 * The assumptions are things that need to be in place for the Use Case to be met
 * The following statements were proposed to be revised as requirements and should be moved to the Functional Requirements section:
 * The Provider Directory returns Electronic Service Information (including electronic address and security information) as discrete data
 * Provider Directory systems have controls to ensure that destination information is maintained in a secure manner and that information is shared only with authorized users
 * Provider Directories can support a relying party agreement which may address accurate, timely, and complete data, legal and governance policies, data access authorizations, data ownership, and data use
 * A Provider Directory will provide at least one secured and guaranteed delivery transport mechanism
 * Pre-conditions
 * The Use Case applies to a broad group than providers, so providers should be replaced with destinations
 * Post-conditions
 * No revisions were discussed and made
 * Actors and Roles
 * Providers should be replaced with destinations
 * Electronic service Information should replace electronic address and security information
 * Diagrams (Use Case, Context, Activity, and Sequence Diagrams)
 * In the Activity Diagram, the Provider Information Directory should return data about the destinations other than just the electronic service information to allow the consumer to select the appropriate destination and thus its electronic service information
 * Scenario
 * Since the security information is inclusive in the Electronic Service Information returned, the reference to the Query for Digital Certificate Use Case for Direct Project should be made only when the Provider Directory does not return the digital certificate associated with Direct Addresses
 * The Provider Directory can conditionally return the digital certificates for Direct Addresses
 * Functional, Information Exchange, and System Requirements
 * Some of the assumptions highlighted as potential requirements should be moved to this section. This will be presented and discussed further during the Sprint Team
 * Appendices
 * The group discussed revisions on the definition of Electronic Service Information from Karen Witting. The use of “Messaging Framework” and its examples may be perceived differently by others, thus a clarification would be beneficial.
 * The suggestion to replace examples of Messaging Framework as SMTP, HTTP/SOAP was accepted

//**Resolution(s):**//
 * Overview and Scope - Policy Issues
 * Revised the Privacy and Security policy issue description to “Provider Directories will need to have the capability to comply with local, regional, and national policies regarding discoverability, privacy, and security”
 * Use Case Assumptions
 * Revised and suggested to move the following statements to the Functional Requirements section to be:
 * The Provider Directory returns Electronic Service Information (including electronic address and security information) as discrete data
 * Provider Directory systems have controls to ensure that destination information is maintained in a secure manner and that information is shared only with authorized users
 * Provider Directories can support a relying party agreement which may address accurate, timely, and complete data, legal and governance policies, data access authorizations, data ownership, and data use
 * A Provider Directory will provide at least one secured and guaranteed delivery transport mechanism
 * Eliminated “valid and reliable” from the statement “Provider Directories have valid and reliable algorithms for identifying providers that match the query parameters”
 * Pre-conditions
 * Replaced providers with destinations
 * Actors and Roles
 * Replaced providers with destinations
 * Replaced “electronic address and security information” with “Electronic service Information”
 * Diagrams (Use Case, Context, Activity, and Sequence Diagrams)
 * Modified step 3 to read “Return data on destinations matching query parameters including their electronic service information”
 * Scenario
 * Under User Story, replaced “appropriate destination’s system” with “appropriate destination’s electronic service”
 * Replaced “any required security information” with “digital certificate(s) for Direct Addresses” for data returned conditionally
 * Functional, Information Exchange, and System Requirements
 * Included assumptions highlighted as potential requirements to be presented and discussed further during the Sprint Team meeting
 * Appendices
 * Revised definition of Electronic Service Information to “All 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, query for patient/provider/healthcare data). The information should include the type of information (e.g. patient summary or query) the destination’s Electronic Address (see definition above), the Messaging Framework supported (e.g. SMTP, HTTP/SOAP), 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 labels which help identify the type of recipient (e.g. medical records department).”


 * Logistics and Next steps:**
 * Recurring SWG Meetings occur every Thursday 12:00-1:30PM ET
 * Next SWG Meeting scheduled for August 4, 2011 12:00-1:30PM ET
 * Next Sprint Team Meeting scheduled for August 5, 2011 3:00-5:00PM ET
 * Present revised Use Case to Sprint Team for any additional revisions
 * Review the Use Case and provide comments using the discussion threads for each section
 * Respond to posted topics/requests under the discussion thread