PD+-+Sprint+Team+Meeting+Summary+2011-06-03


 * Date**: June 3, 2011
 * Name**: Provider Directories (PD) Sprint Team Meeting Session 1

Agenda/Objectives:

 * **Topic** || **Time Allotted** ||
 * Project Scope Revision || 15 minutes ||
 * User Stories || 45 minutes ||
 * Use Case Content Development and Assignments || 15 minutes ||
 * Identification of Community Volunteer Leads/Co-Leads || 5 minutes ||
 * Sprint Team Logistics || 5 minutes ||
 * Next Steps and Questions || 5 minutes ||

Attendees:
__Workgroup Attendees:__ Bill Beighe, Greg Rehwoldt, Victor Daye, John Sanchez, Ernest Grove, Tynisha Carter, Judith Fincher, john mattison, Gail Kocher, Ryan Balsick, Erik Pupo, Sam Elias, Jamie Welch, Mara Robertson, Bob Kaye, Christine Sher, Robert Dieterle, Patrick Pyette, Robert Thurston, Teresa Strickland, John Feikema, Susan Campbell, Donna Jones, David Tao, kory Mertz, Barbara Drury, Sara Lambert, Nagesh Bashyam (Dragon), Jim Bialick, Laurance Stuntz, Karen Witting, Laura Megas, Melissa breen, Daniel Kalwa, Coletta Dorado, Galen Mulrooney, Robert Levy, Patrick Murphy, Sorin Davis, Jennifer Sisto, Francis Chan, Stephen Witter, David Susanto, Lou Lunetta, Laura Edens, Steven Clark, Chris Andreou, McLain Causey, Deanna Nole, Gregg Seppala, Peter Bachman, Ken Pool, Steven Riney, cletis earle, Sri Koka, Bob Yencha, nam nguyen, Debra Rouse, Joy Styrcula, John Moehrke, Vincent Lewis, laron rowe, jeff Ice, Brad Schoffstall, Lester Keepper, lin wan, Smriti Singal, Walter Suarez, Amram Ewoo, Terri Skalabrin, Scott Chapin, David Dissinger, Dawn Heisey-Grove, Margaret Weiker, Paul Cartland, Thompson Boyd, Darrell Kauthen, Serafina Versaggi, Lisa Briggs, Will Rice, Ed Larsen, Peter Gilbert, Antonio Perfeito, Don Bechtel, Ron Sawdey, Sandra Schafer, Vishal Raina

__Panelist Attendees:__ Victoria Njoku, Virginia Riehl, Jitin Asnaani, Heather Stevens

Action Items:
http://wiki.siframework.org/PD+-+Sprint+Team+Sub-Workgroup+Sign+Up+Page
 * Action Item || Status / Next Steps || Lead || Contributors || Due Date ||
 * Form 3 sub-Workgroups || Sign up 3 sub-Workgroup (SWG) meetings
 * Certificate Discovery under Directed Exchange
 * Certificate Discovery under Pull-based Exchanges
 * Minimum Data Elements for Provider Directories

SWG Meeting Schedule Options Virginia Riehl || Jonathan Tadese || 6/6/2011 || Virginia Riehl || 6/6/2011 || Virginia Riehl Jonathan Tadese ||  || =Use Case Content Discussion=
 * Monday 2:30-4:00PM
 * Monday 4:00-5:30PM
 * TBD || Victoria Njoku
 * Complete homework Items || Rewrite User Stories for review and discussion during both 6/6 SWG meetings || Bob Dieterle || Victoria Njoku
 * Review posted Meeting Summary || Review posted 5/27 Meeting Summary || All Sprint Team Members ||  || 6/6/2011 ||
 * Sign up on wiki as Committed Member (if not already) || Sign up on wiki as Committed Member (if not already) || Sprint Team Members || Victoria Njoku

Key Discussion Points:

 * ONC is committed to all different types of exchange frameworks and seeks to support all provider directories efforts underway
 * The problem to be solved under a directed exchange is clear, however, the problem for other exchange frameworks needs to be further defined by community.
 * Three work streams will be main focus for the community were presented i.e.
 * Certificate discovery when an endpoint address is known such as an Direct email address
 * This work has high urgency as most state HIEs are currently developing provider directories and charge from HIT Standards Committee
 * This effort can be completed within the next six weeks
 * Existing standards will be analyzed and recommendations of potential standards that can be adopted will be shared with the HITSC. Standards that will not meet the need will be eliminated from the interim final rule, leaving one or two standards to support this type of exchange.
 * Reference implementations and pilots will also be conducted
 * Service endpoint discovery
 * There is great need for provider directories for other types of exchanges. For example, in terms of query/retrieve for a SOAP service, there is a need to query to those SOAP service endpoints
 * There is a need here to determine whether there is shorter/intermediate stage where if one has some “initial location” about a SOAP endpoint for example, one can use a standard to figure out that particular endpoint
 * If there is no intermediate stage that requires using a standard to determine the endpoint when an initial location is known, then the focus can be directed to using some basic provider attributes to discover that endpoint.
 * Minimal data elements for a provider directory
 * The goal is to work jointly with the State HIE Community of Practice to define the data elements for a provider directory that HIEs can use to support their current developments
 * Clarifying the goals and potential solutions for the certificate and service endpoint discovery work stream:
 * It appears that part of the goal is to leverage the existing standards and support new standards.
 * There is need for clarification and confirmation whether the goal applies to two cases where: 1) a system will either have an interface which has the endpoint for the initial connection that responses back to say it can handle these different types of protocols and instead of returning the endpoints for those different protocols, it just makes it a proxy or a pass through once that protocol is selected so that the end system does not have to worry about it, or 2) the system returns those endpoints and can do a direct connect with the standards that they currently have in play.
 * These are potential solutions and there will be more work to figure out the model to determine the connection and endpoints
 * One of the issues to address is how to deal with situation where multiple providers in one system have the same endpoint for multiple providers as in a hosted model. There has to be a way of lowering this down on the initial communications, and then discovering what those initial capabilities are.
 * For service endpoint discovery, the key question is what work can be defined now to come up with in a short period of time.
 * This can be based on something referred to as an “Oreo” which is an old terminology for path through. That is, if one wanted to be in between two websites, one could handle the initial connection and then the data would flow exactly through. One would know the endpoint on the other end however the client on the front end would not but that endpoint has been verified on that first connection. The data would just flow back and forth through using the exact protocol that was established for that standard, but one has to have the initial front end to make all of the choices or workflow work and then once that connection is established, the system is basically just a network router that is routing to the other web service.
 * This approach can be proposed by making the front end generic enough to cover all of the different scenarios and allowing for future standards, which makes it a lot easier at least for developers. If developers want to support certain standards that is all apart of that first initial connection with the certificates from a central location or lookup for the provider and then after they have established themselves and they see the standards and agree upon a particular communication that same interface will then go into the mode of connecting directly internally and pass through the mode for that standard.
 * This description appears to indicate that the provider directory service can also be the router. In this case, one question is whether there is an assumption that HIEs can have the capability to discover endpoint address and route data. Also, another assumption that needs clarification is whether HIEs or EHRs or other endpoints can discover everything necessary to connect directly over the internet without using anything as an intermediary.
 * There may be endpoint problems where there is need to ensure other systems know how to communicate, other than that one standard as a path through appears sufficient
 * Unless there is an assumption that what happens is that those endpoints are registering their capabilities within the provider directory and one way or the other one can look them up and discover those endpoints, it will be a question of how far the endpoints ability need to be specified to both speak of protocol and to consume a payload.
 * There is also a programming issue of having that endpoint as a valid domain in the system’s programming language to be able to connect to it.
 * One question to address is whether there is one framework or multiple frameworks that provides the ability to talk to the provider directories and obtain the information necessary to then select a different messaging framework or use the same one to communicate directly with the other endpoint.

Resolutions:

 * Proposed approach for allocating resources to support creation of the use cases for the exchange models
 * There will be two separate work streams. One work stream already has the use case clearly defined, but will need to incorporate comments and undergo improvements by the community. The second work stream is a step behind and needs to focus on framing the problem better. Those work streams are going to meet independently.

Key Discussion Points:

 * The top level user story appears more like a technical situation, not a clinical one.
 * It may need to have an assumption to clearly define it.
 * One assumption could be that the provider has established some level of trust to get the security credentials. However, if one has established that trust, the question is whether there is a need for a mechanism to discover the certificate.
 * There is some perception that the first use case for the certificate discovery appears too constrained and may not be valuable for many providers, but only valuable for providers using directed exchange.
 * From ONC’s perspective, this use case is of high value for directed exchanges and needs to be resolved urgently
 * There should be a user story to discover endpoint address as well not only certificates for other exchange frameworks
 * The different work streams as stated make sense to focus on discovering certificates under directed exchange, some certificate/key under other exchange frameworks, and discovering endpoint address if not known.
 * The use of certificate, public keys, and security information have been used interchangeably, there should be one term to avoid any confusion
 * VPN or private key can be used instead
 * It is preferable to use certificate. A certificate is associated with a set of keys.
 * In regards to HISP to HISP discovery, it is not certain that we will address that within this work
 * Definition of Electronic Endpoint Address
 * The definition of an endpoint or electronic address needs to be clarified.
 * Given that we are considering looking up the directory to get the credentials to connect initially to the system, it is needs to be clear what is considered an endpoint address.
 * With a routing mechanism present, the endpoint address could be an email address
 * One proposal for a definition of an endpoint is what is used in programming language: an endpoint is the system that one will be talking to. The address for example will be an IP address.
 * Specifying an endpoint as an IP address may not be satisfactory, it may not get one very far compared to URI. It may be preferred to use URI if considering multiple protocols.
 * An endpoint could be something that has the schema or protocol attached to the address.
 * Addressing concern of provider liability for certificate discovery
 * There needs to be a way to protect providers from liabilities in case there is no specification for this. The group may be overlooking providers who want to be protected
 * This will be addressed based on two assumptions: 1) Trust has been established, 2) Endpoint Address will be defined.

Resolutions:

 * For certificate discovery, two assumptions should be included: 1) Trust has been established, 2) Endpoint Address will be defined.
 * The term “electronic address” will be used instead of endpoint address or electronic endpoint address
 * The use case for certificate discovery will be called Healthcare Certificate Discovery Use Case as opposed to Provider Certificate Discovery Use Case
 * Bob Dieterle volunteered to revise the current user stories and present them for review and discussion during the two sub-workgroups scheduled for Monday at 2:30pm and 4:00pm.
 * Both sub-workgroup members will finalize the user stories and present them back to the Sprint Team on June 10th.

Key Discussion Points:

 * Three sub-workgroups were introduced based on the project scope presented earlier
 * The sub-workgroups include:
 * Healthcare Certificate Discovery under Directed Exchange SWG
 * Healthcare Certificate Discovery under Pull-based Exchanges
 * This group will work in parallel with the Directed Exchange SWG and its work will progress into the discovery of electronic addresses in Phase 2
 * Minimum Data Elements for a Provider Directory
 * This group will work jointly with the State HIE Community of Practice (CoP), whom have initiated work already in this area.
 * More details will be shared on the project plan and activities of this group soon
 * A volunteer lead was solicited, however, no one volunteered yet.

Resolutions:

 * Sprint Team members were asked to send an email to the support leads if interesting and willing to occupy position.

Key Discussion Points:

 * The need for a community volunteer lead was introduced and members were asked to indicate their interest
 * No one volunteered during the call.

Resolutions**:**

 * Sprint Team members were asked to send an email to the support leads if interested and willing to occupy take on the role

Key Discussion Points:

 * Recurring Sprint Team Meetings occur every Friday 3:00-4:30PM ET.
 * Next Sprint Team Meeting scheduled for June 10, 2011 3:00-4:30PM ET
 * Face to Face (F2F) full-day meeting, June 15, 2011. Register at http://wiki.siframework.org/June+F2F+Meeting+Registration
 * Members who are not able to attend in person can participate via teleconference. More details will be shared soon
 * Presentation on Use of Provider Directories in Canada (by Ron Parker) TBD
 * Presentation on Australia’s Human Services Directory (by Max Walker) TBD

Key Discussion Points:

 * Sign up for Sub-Workgroups (SWG)
 * Certificate Discovery under Directed Exchange
 * Certificate Discovery under Pull-based Exchanges
 * Minimum Data Elements for a Provider Directory
 * SWG Meeting Schedule Options
 * Monday 2:30-4:00PM
 * Monday 4:00-5:30PM
 * TBD
 * Complete homework Items
 * Review posted Meeting Summary
 * Sign up on wiki as Committed Member (if not already)