Electronic+Address+Discovery+SWG+Meeting+Minutes+2011-07-07


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

**Agenda/Objectives:**

 * **Topic** || **Time Allotted** ||
 * Dataset Considerations || 80 minutes ||
 * Sprint Team Logistics || 5 minutes ||
 * Next Steps || 5 minutes ||

**Attendees:**
__Workgroup Attendees:__ Ed Larsen, David Susanto, Vincent Lewis, Karen Witting, Robert Dieterle, Rao Parvatam, Michael Nelson, Ananya Gupta, Bob Yencha, Don Jorgenson, Diana Massey, Steve Witter, Ron Sawdey, Steve Tripp, Lester Keepper, Ken Pool, Scott Chapin, Aleena Dhar, Jitin Asnaani, Jas Singh, Dave Marotz, Mary-Sara Jones, Gail Kocher, Peter Bachman, Terri Skalabrin, Emily Mitchell, Kory Mertz, Sandra Schafer, lin wan, Erik Pupo, Dan Kearney

__Panelist Attendees:__ Bob Dieterle, Virginia Riehl, Victoria Njoku

**Action Items:**

 * **Date** || **Description** || **Status** || **Notes** ||
 * 7/8/11 || Review updated dataset considerations section and provide comments on Wiki || OPEN || SWG and Sprint Members ||

**Dataset Considerations**
//Key Discussion Points://
 * The data elements assembled by the small volunteer group led by Bob Dieterle was discussed starting with the datasets for the query message
 * At the individual level, data elements including name (first, last, and middle), gender, specialty, etc. was agreed upon by the group as information to include in the query message
 * For physical address– one assumption made is that the individual is associated with a service/entity address. The combination for entity and service address is used to query and would return multiple entries because of multiple associations with entities. One concern about this assumption is the forcing of linkages to get information e.g. how does one that know if individuals or entity are associated
 * For the entity level, data elements including name, service address, entity type, and telephone number were discussed and agreed upon.
 * It was noted that an entity could have multiple endpoints
 * The use of section descriptions was discussed and it was deemed necessary to keep in order communicate to potential readers better and that grouping of data elements is logical in the Use Case. This structure has been used for other Use Cases
 * The group saw a need to clarify/define certain terms used in the section description including individual, entity, and non-person, non-endpoint (NPNE)
 * For Non-person, non-endpoint (NPNE), a request was raised to clarify the difference between NPNE and entity. An example is a general email inbox. It could be where medical records are located like a department, not necessarily an entity itself.
 * There was some interest to change the name of the actor “Provider Directory.” Options including Electronic Service Endpoint Directory or Electronic Endpoint Directory or something similar were presented. This topic and options will be discussed and considered at a later stage if the group still sees interest in changing the name.
 * The group discussed and agreed on having one response and query message
 * The data element, DBA, name could be anything like business name,
 * The unique references section has data elements such as NPI that are applicable to the individual, entity, or sub-entity levels and this was noted in the document.

//Resolution(s)://
 * Definition of Individual and Entity were developed.
 * Individual is a person who is licensed or certified to provide healthcare services
 * Entity is an organization engaged in healthcare related services
 * Non-person, non-endpoint (NPNE)
 * NPNE was preferred to be referred to as sub-entities.
 * A sub-entity was defined as a characteristic within an entity.
 * For Individual level datasets under the query message, Address and Telephone number were added
 * For the Entity level datasets under the query message, City, state, Country, etc. were added to clarify “Service Address” and Sub-Entity Destination was added as an additional data element
 * The Non-Person, Non-Entity (NPNE) Destination set of data elements was removed in order to merge the data elements with that of the Entity level.

**Logistics and next steps:**

 * The data elements for the return message will be discussed and refined at the next meeting.