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

**Time:** 12:00PM - 1:30PM EDT **Dial-in:**1-408-600-3600 | **Passcode:** 666 076 389
 * Electronic Service Information Discovery Workgroup Call **
 * Date: **09/15/2011

Ken Pool, Lin Wan, Shay Paintal, Scott Chapin, Robert Dieterle, Naveen Amiruddin, Richard Eshbach, Mike Woodcock, Tynisha Carter, Gail Kocher, William Ryan, Sam Dechario, Karen Witting, Terri Skalabrin, Virginia Riehl
 * Attendance: **


 * Action items:**
 * Support team will touch base with ONC for further guidance on accessing and using closed code sets (pay for access/restricted licenses) and explore what can be made publicly available from those items with intellectual property rights.
 * Support team will discuss with ONC the option of starting a workgroup focused on creating our own open access code sets with ONC.
 * Bob Dieterle will write up descriptions (with examples) of what a query/response for the two data elements within Provider Directory section entail. This will be posted to the wiki with a discussion section for people to comment before the next call.


 * Meeting Minutes:**
 * Have to think in terms of cost for extended code sets from HPD (healthcare taxonomy provider code set is maintained by NACC; no charge for paper printed or CSV but there is a charge for electronic version)
 * Organization Provider Type & Organization Provider Speciality
 * The taxonomy codes’ purpose is to provide “provider specialty” not to provide “provider type”
 * Decision: Continue to use ISO 21298 to identify “provider type”; use healthcare taxonomy code set for “provider specialty”
 * ISO and taxonomy code sets have been added to the works in progress section of the Wiki.
 * ISO 21298 will be recommended but not required
 * Action Item: Defer decision until group members have opportunity to review standards provider type code set elements
 * Action Item: Support staff will touch base with ONC for further guidance on accessing and using closed code sets (ie pay for access/restricted licenses). What can be made publicly available from those items with intellectual property rights?
 * We may have to define/create unique code sets.
 * Action Item: Discuss option of creating a workgroup focused on creating our own open access code sets with ONC. (Support Team)
 * Organization Specialty
 * HPD requires ISO 21298 but allows for extension
 * Individual provider type
 * Use ISO 21298 code set (see Organization Provider type above)
 * Individual Specialty
 * Use either ISO 21298 or provider taxonomy code sets (see Organization Specialty type above)
 * Individual Gender
 * Needs a category other than M and F.
 * No entry or null option is necessary for unknown or indeterminate situations
 * Individual NPI
 * An individual can only have a single Type-1 NPI. If they are issued more than one, there has been an issue. We do not need to allow for multiple NPIs.
 * Unique Provider Directory Reference
 * Unresolved who will define these reference strings
 * Data model may need a reference to the provider directory so that searcher can return to that directory later
 * Want to enable without specifying that PDs might act in something of a federated fashion
 * Disagreement amongst group members over what a query/response looks like.
 * Action Item: Bob will write up descriptions (with examples) of what a query/response for the two data elements within Provider Directory entail. This will be posted to the wiki with a discussion section for people to comment before the next call.
 * Organization – Organization Relationship
 * Relationship Type
 * Sufficiently robust types may not exist. Relationships are too complex and tend to change too often. It may be much simpler to just say organization A “is a member of” organization B.
 * Alternative is “Parent of” and “Child of”
 * Decision: Change “From Organization ID” to “Parent Organization ID” and “To Organization ID” to “Child Organization ID”
 * Decision: Remove “Relationship Description” and “Relationship Type”
 * “Relationship Status” may be unnecessary. If there is a change in relationship, that change should be reflected in the Parent/Child data element, thus the Status would be irrelevant.
 * Decision: Delete “Relationship Status”
 * Data Object Set
 * Prefix
 * Should we avoid gender related titles and solely use honorifics?
 * “Dr.” seems too vague; would prefer to know details such as MD, DO, DDS, etc
 * No authoritative list exists
 * Decision: Prefix limited to honorary title, if desired
 * Suffix
 * Decision: Limited to generational identifier, if appropriate
 * Credentials
 * “Status” element added to object
 * Digital Certificate Object
 * Distinguished Name – Is this attribute necessary? Is there a use for this outside of the Digital Certificate? It is part of the LDAP structure and can be used for searching an LDAP directory.
 * The outside group that has been working on Microdata is now going to join us and operate within the S&I framework.
 * Support team will assemble the work outside group has already completed and post it under a references section to the Wiki