Electronic+Address+Discovery+SWG+Meeting+Minutes+2011-06-30


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

Agenda/Objectives:

 * **Topic** || **Time Allotted** ||
 * **Data Set Considerations**


 * //Description//**: Present and discuss data elements proposed by small group of SWG members (Gail Kocher, Robert Dieterle, Lin Wan, Scott Chapin, Margaret Weiker, and Steve Witter)


 * //Desired Outcomes//****:** Develop //Data Set Considerations// section for future discussion

- Recurring SWG Meetings occur every Thursday 12:00-1:30PM ET. - Next Sprint Team Meeting scheduled for July 1, 2011 3:00-5:00PM ET - Next SWG Meeting scheduled for July 7, 2011 12:00-1:30PM ET
 * //Lead//**: Bob Dieterle, Gail Kocher || 80 minutes ||
 * **Sprint Team Logistics:**


 * //Lead//**: Victoria Njoku || 5 minutes ||
 * **Next Steps**

- Review full Use Case and provide comment on Wiki (if any) to be addressed prior to or during 7/1 meeting

__Workgroup Attendees:__ Ron Sawdey, Steve Tripp, Aleena Dhar, Kelly Conlin, Galen Mulrooney, Diana Massey, Jitin Asnaani, gene ginther, Lester Keepper, Chris Andreou, Scott Chapin, Ernest Grove, Dan Huber, Smriti Singal, Jonathan Tadese, Erik Pupo, Dan Kearney, Ananya Gupta, Jennifer Sisto, Virginia Riehl, Robert Dieterle, Ed Larsen, Gail Kocher, Steve Witter, Emily Mitchell, Jas Singh, Jamie Welch, lin wan, Karen witting, Sandra Schafer
 * //Lead//**: Victoria Njoku || 5 minutes ||
 * Attendees:**

__Panelist Attendees:__ Victoria Njoku, Virginia Riehl, Bob Dieterle, Gail Kocher, Erik Pupo, Jonathan Tadese


 * Action Items:**
 * **Date** || **Description** || **Status** || **Notes** ||
 * 6/30/11 || Bob Dieterle will revise data elements incorporating feedback and using Use Case format and will send to Victoria for dissemination upon completion || In Progress ||  ||
 * 6/30/11 || All SWG members who were not part of the small workgroup and would like to provide feedback on the revised content should send an email to Victoria indicating their interest to participate || In progress ||  ||

//Key Discussion Points://
 * Dataset Considerations**
 * The work (i.e. conceptual schema of Provider Directories) developed by the State HIE Community of Practice (CoP) was leveraged to develop the initial dataset considerations for the Use Case
 * The purpose of the CoP’s schema is to support the ability to search for an individual and/or entity
 * An individual is at the single person level; entity level is at the organization level.
 * Five different groups of information were considered i.e. Contact Information, Direct Address and Certificate Information, Physical Address, and Service-Node information
 * It was noted that the inclusion of “Wildcard” as well as non-person endpoints and gender had not been confirmed and therefore the group would need to help in making that decision
 * After this introduction of the spreadsheet Bob and Gail went through to explain the structure of the current spreadsheet and how it appeared to be organized and received a lot of specific feedback from the group
 * The parameters of this exercise was interpreted as to discover the maximum allowable number of data elements
 * Definitions or clarifications of certain terms and acronyms were requested including: alternate individual, non-person endpoint
 * In terms of presenting the data elements within the Use Case, it was suggested that the requirements be a bulleted list instead of a table since the goal of this workgroup was to identify the functional requirements and not indicate any standards information; however it was noted that the Use Case Simplification group has been working on a standard template for all functional requirements artifacts that need to be handed over to the harmonization work stream, and therefore a table would be used to outline the requirements and dataset considerations.
 * Specifically, the dataset considerations would include columns to outline the Section description (e.g. Individual or Entity), Data elements (e.g. First Name, Last Name), and Additional Notes (i.e. to provide any additional/supportive information for each data element that can be leveraged during harmonization
 * Using “Unique ID” as a data element appears technology-specific and would be different for any entry in each Provider Directory. It was also perceived as a “nice-to-have” data element. The group preferred and decided to use “Unique Reference to […] Entry in Provider Directory instead where […] could be individual, entity, etc.
 * A large part of the discussion revolved around the idea of the definition of “Required” and what it means in terms of the artifacts this workgroup is tasked with producing. The support leads reminded the group that they have been tasked with identifying the complete set of data elements that they would want to see in a message. Therefore, “required” in that sense means that all of these data elements are those that are necessary to be supported by the sender and the receiver. In terms of what actually gets put in the query / in the message depending on the cardinality/optionality i.e. what becomes prescriptive for Provider Directory consumers, that is to be decided by the harmonization group which will analyze the best fit in terms of standards. That effort is not to be done within this Use Case discussion.
 * There was discussion on whether contact information should appear multiple times for different groups such as individuals and entities. There are providers that are solo practitioners who operate as a sole entity so contact information here is only associated to that person. Such providers do not have a separate legal entity for their proprietorship and they operate under their social security numbers.
 * The group decided to indicate contact information multiple times for any of the applicable groups, at least once for individual and another for entity
 * In regards to whether information on DURSA being signed should be retrieved, the group preferred this to be a future discussion.
 * There was a suggestion to add a section in the Use Case for future steps in the process where parking lot items can be discussed later and to avoid concern that the information will get lost in the transition from Use Case Development to Harmonization.
 * Support Leads indicated these ideas are being captured within the issues and obstacles section of the Use Case or parking lot items in the meeting minutes. In addition, there has been representation from the Harmonization leads on each of the calls ensuring that key concepts, issues, and general parking lot items will not get lost in translation

//Resolution(s)://
 * Definitions or clarifications of certain terms (e.g. alternate individual, non-person endpoint) should be provided
 * Discussion on retrieving DURSA signed information will be deferred to a future discussion
 * Bob Dieterle will revise the data elements from the spreadsheet based on input that was received and present it in the Use Case format with the appropriate level of detail for next week’s discussion.
 * Standards Harmonization will look at existing technologies and pick a particular standard for implementation
 * Purpose of the Use Case and the Workgroup right now should be to specify the minimal required elements.
 * The standard must specify how to code name in query request. It will then go on to determine whether or not this must be populated for every query request. The Use Case should not be driving to a particular standard.


 * Logistics and next steps:**


 * The SWG deferred the discussion on datasets as part of the Friday 7/1 Sprint Team meeting until it meets again next week so members have enough time to discuss and develop the content more and then populate the Use Case appropriately
 * Once the revised data elements content is received from Bob Dieterle, Victoria will disseminate to the rest of the small workgroup and any other members interested in providing feedback
 * Other members interested in providing feedback on the revised content along with the small group should send an email to Victoria and she will include them in the communication