PD+-+Sprint+Team+Meeting+Minutes+2011-07-15


 * Date**: //7/15/2011//
 * Name**: //Provider Directories (PD) Initiative Sprint Team// Meeting //7//

Agenda/Objectives:

 * **Topic** || **Time Allotted** ||
 * Initiative Updates and Announcements || 5 minutes ||
 * Query for Digital Certificate Use Case Direct Project || 30 minutes ||
 * Query for Electronic Address Use Case || 80 minutes ||
 * Sprint Team Logistics/ Next Steps and Questions || 5 minutes ||

Workgroup Attendees:
JOHN MOEHRKE, Ernest Grove, Ken Poo,l Odysseas Pentakalos, Al Manint, Lester Keepper, Walter Suarez, Craig Klassy, david tao, kris cyr, Terri Skalabrin, Steve Rushing, vince lewis, Peter Bachman, Ananya Gupta, Lin Wan, Mary Lynam, McLain Causey, Thompson Boyd, Aleena Dhar, Ryan Balsick, Dave Shevlin, Kory Mertz, Derrick Evans, Tynisha Carter, Charlene Harven, Bob Kaye, Francis Chan, Joni Bass, Debra Rouse, Donald Cole, Erin Cornell, Ed Larsen, Scott Chapin, Donna Jones, Dan Kearney, Sri Koka, Shannon Moore, Chris Andreou, Kelly Conlin, annamarie saarinen, Jitin Asnaani

Panelist Attendees:
Karen Witting, Bob Dieterle, Virginia Riehl, and Victoria Njoku

Action Items:

 * **Date** || **Description** || **Status** || **Notes** ||
 * 7/15/11 || Review and provide additional comments on updated Query for Electronic Address Use Case || OPEN || Sprint Team Members ||
 * 7/15/11 || Revise introductory sections of Query for Electronic Address Use Case and address comment received || OPEN || Sprint Team Members ||
 * 7/15/11 || Review posted Meeting Minutes for Sprint Team and SWG meetings and provide any corrections || OPEN || Sprint Team Members ||

Query for Digital Certificate Use Case for Direct Project:

 * Key Discussion Points:**
 * The discussion for the Issues, Obstacles, and Potential Risk section focused on the following:
 * Les Keepper and Ernest Grove’s “No” votes and comment related to a request to include some statement around the need for authentication to get the certificate to avoid fraudulent access to data and information from EHRs
 * He indicated that in the security trust agent relationship and the DNS there has to be an upfront confirmed authentication authorization that goes along with each action and user relationship.
 * The suggestion was to add the statement “upfront authentication authorization on an actual, physical, biometric relationship”
 * Some members clarified that access to digital certificates for Direct needs to be done through an “accessor” validated process
 * It was noted that the transaction in this use case does not give one access to EHR data, instead it gives one access to a public certificate
 * Some members clarified that the security and clinical risks statement included at the last meeting appear to address this issue already, however the commenter did not agree that if fully addressed the concern around fraudulent access to EHR data
 * The Use Case does not preclude a Certificate Directory from doing authentication if it wants to, it also does not force a Certificate Directory to authenticate
 * Another clarification was provided that Direct requires digital signature to do authentication, specifically, a Direct message must be signed by the sender and their certificate must be included in the message (end to end)
 * The group noted that this is a policy issue and not to be set as a standard, which would enable the market to make the final decision. It is not applicable to discuss in this Use Case
 * The group did not make any revisions and requested for Les Keepper and Ernest Grove to further consider the discussion and whether they were satisfied to change their vote
 * Brett Peterson and McLain Causey’s “No” votes and comment related to removing the statement “the use of certificates issued by Certificate Authorities that are not cross-certified with the Federal Bridge creates a risk that they may not be interoperable with the federal entities using the Direct Project” as it relates to usage of certificates which is out of scope
 * The group emphasized that the statement does not mandate the use of certificates issued by Certificate Authorities that are cross-certified with the Federal Bridge, but that is was an important issue to highlight
 * The group addressed a comment from David Tao regarding adding the word “inadequate” to the following statement “capability of digital certificate requester systems to use and manage digital certificate(s)” so that it sounds more like a issue or risk
 * The discussion for the Out of Scope section focused on the following:
 * A workgroup member would like to acknowledge the that the discovery of a direct address will be covered in the Query for Electronic Address Use Case
 * The discussion for the Challenge Statement section focused on the following:
 * David Tao’s comment indicated that the following clause “Where the digital certificate is not already known” needed to be clarified to say “where the sender does not possess the receiver's digital certificate”
 * The former clause may imply that one always has to query the directory for the certificate, however, it was clarified that if the certificate has been cashed, then the Use Case will not apply
 * No changes were made to the Use Case Assumptions section as it was unclear what revision was needed to address John William’s comment “Identity proofing of certificate applicants by certificate authorities should conform to the Direct Project Rules of the Road, and Communities work groups”
 * The discussion for the Post Conditions section focused on the following:
 * David Tao suggested to remove the word “system” from “the digital certificate requestor system”. The digital certificate requester can be a human instead of a system
 * The discussion for the Use Case Diagram section focused on the following:
 * David Tao requested for clarification why the "systems" in the diagrams at each end are shown as "human" icons and also that the Use Case, Context, and Activity diagrams appear redundant
 * The purpose of each diagram was discussed but specifically the clarification provided was that UML modeling icons represent systems as people and the diagrams need to be compliant
 * No Changes were made to the Use Case Diagram section
 * The discussion for the User Story section focused on the following:
 * David Tao suggested removing the word “system” from “the digital certificate requestor system” phrase in the statements similar to those in the Post-Conditions
 * The discussion for the Glossary section focused on the following:
 * Karen Witting suggested a new definition for Direct project, using the definition from the Direct project overview
 * The use of the word “Direct” and its definition was disputed and deemed confusing to include in the Use Case in addition to “Direct Project”
 * The use of “Direct Specifications” in place of “Direct” was considered, but an argument was raised that the use of “the Direct Project” can serve a similar purpose and be used in place of “Direct” across the Use Case
 * As a result, every use of “Direct” should be replaced with “the Direct Project”
 * Resolution(s):**
 * Revisions to the Issues, Obstacles, and Potential Risk section are as follows:
 * Lester Keeper and Ernest Grove did not change their votes but will speak with John Moehrke offline to discuss his statement in regard to upfront authentication authorization. The Support Leads will also have another offline discussion.
 * Support leads Virginia and Victoria will reach out to Brett Peterson offline in regard to his comment and vote and to provide clarity about why the group introduced the statement around cross-certification and also why they feel is important to keep in the Use Case
 * The word “inadequate” has been added to the following statement “inadequate capability of digital certificate requester systems to use and manage digital certificate(s)”
 * Revisions to the Out of Scope section are as follows:
 * The statement “Discovery of a Direct Address” has been revised to the following “Discovery of a Direct Address, which is covered in the //Query for Electronic Address Use Case”//
 * Revisions to the Challenge Statement section are as follows:
 * “Where the digital certificate is not already known” has been revised to state the following “the sender does not possess the receiver's digital certificate”
 * Revisions to the Use Case Assumption section are as follows:
 * Support leads Virginia and Victoria will reach out to John Williams offline in regard to his comment to identify the specific revision he is suggesting
 * Revisions to the Post Conditions section are as follows:
 * The word “system” has been removed from “digital certificate requester”
 * Revisions to the User Story section are as follows:
 * The word “system” has been removed from “digital certificate requester”
 * Revisions to the Glossary section are as follows:
 * Definition for Direct Project was updated using the definition from the Direct project overview
 * The definition for “Direct” was deleted
 * Every use of “Direct” was replaced with “the Direct project” across the Use Case

Query for Electronic Address Use Case:

 * Key Discussion Points:**
 * The discussion for the Dataset Considerations section focused on the following:
 * It was clarified that the discussion of required vs. optional data elements should be discussed during harmonization
 * Unique reference was used more generally for each group of data elements and does not specify how it is assigned or who creates it because the latter is technology dependent and should be discussed in harmonization
 * The discussion of audit trails should also be part of the harmonization work
 * When completing a query it is not expected that an individual will specify multiple Direct Addresses, however in the response there may be multiple
 * Group discussed changing “direct address” and “email address” to “electronic address”
 * A suggestion was made to delete “Allows for query federation or integrated response from multiple Provider Directories” as federation is out of scope for the Use Case
 * Workgroup member suggested that we change the wording in the following statement “ that returned this row for the query” to remove the word “row” because we don’t know if it will be in rows and this more data modeling discussion
 * In regards to the Individual-Organization relationship, there is need to define the relationship type such as “Member of” and this may require extensive discussion because of multiple methods to define type. This level of discussion is not appropriate at the Use Case level
 * In regards to the Provider Directory section, this section was maintained to provide information about where the electronic address came from even given that is not certain what the implementation would entail. A question was asked if this section was applicable in the Query table and it was determined to be
 * For the return table, a discussion focused on the email and Direct Address within the Individual section.
 * Service Address was clarified to specify city, state, and country as in the query message
 * The word “Service” may be confusing to external readers and may be considered as clinical service. A suggestion was made to change “Service” to “Electronic Service”
 * Use of “Message Type” as a data element under “Electronic Service Information” was discussed and one preference was to use “Transport” because the meaning was not clear and could refer to email


 * Resolution(s):**
 * Revisions to the Dataset Considerations section are as follows:
 * Group will revisit discussion around changing “direct address” and “email address” to “electronic address”
 * The following statement was deleted “Allows for query federation or integrated response from multiple Provider Directories”
 * The following statement “that returned this row for the query” was revised to state the following “from which a set of the data elements are returned”
 * Email (email, usage) was updated to state Email (email, usage) Digital
 * The following statement was added to the individual additional notes section “The usage for Email could be for Direct Project”
 * The group will continue discussion and revision of the return message data elements

__Sprint Team Logistics/ Next Steps:__

 * Key Discussion Points:**
 * Certificate Discovery SWG Meeting rescheduled for **Monday** **July 18, 2:30-4:00PM ET**
 * Electronic Address Discovery SWG Meeting scheduled for **Thursday July 21, 12:00-1:30PM ET)**
 * Sprint Team Meeting scheduled for **Friday July 22, 2011 3:00-5:00PM ET**
 * Completion of Consensus Process for Query for Digital Certificate Use for Direct Project Case and Handoff to Harmonization Team (Targeted July 18th)
 * Initiate Harmonization work for Certificate Discovery for Direct Project work stream
 * Review and provide additional comments on updated Query for Electronic Address Use Case
 * Revise introductory sections of Query for Electronic Address Use Case and address comment received
 * Review posted Meeting Minutes for Sprint Team and SWG meetings and provide any corrections