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

 **Electronic Service Information Discovery Workgroup Call ** **Date: ** 09/08/2011 **Time:** 12:00PM - 1:30PM EDT **Dial-in:**1-408-600-3600 | **Passcode:** **665 794 864 **

Ernest Grove, Zeshan Rajput, Lin Wan, MIke Woodcock, Erik Pupo, David Susanto, Kelly Conlin, Virginia Riehl, Ken Pool, Greg Meyer, Naveen Amiruddin, Naveen Amiruddin, Peter Bachman, Terri Skalabrin, Robert Dieterle, William Ryan, Karen Witting, Sam Dechario
 * Attendance: **

Internal: External:
 * Action Items: **
 * Check WebEx availability, set up call at 10:00 EST on September 12th for Karen and Bob to work through this offline
 * Bob and Karen: Contact URI/URN/URL SME for further information in regards to Policy Type Data Type.
 * Bob and Karen: Research ISO and healthcare taxonomy codesets offline.
 * Bob: Explore current standard for issuance and resolution of multiple NPIs for an individual.


 * Meeting Minutes: **
 * Object Data Set
 * Policy Information Object
 * Participants unsure how data element could be used or generated.
 * Should this be restricted to security information policy?
 * Do we leave a place for something that will be occurring in the future but isn’t fully implemented/supported today?
 * Idea: We need a placeholder for some “policy” stuff, but are not in a position to define it in detail. For example, a link to a written document or a computable document regarding Policy Information and a name.
 * Potential outcome of policy being encoded in digital certificate. However, we are looking at multi use certificates where use is undefined.
 * Decision: Change policy type to computable policy object. This data element holds a data type of URL to such an object. Change Comments to “Use address URL to retrieve the policy object.”
 * Question: Should data type be URI, URN or URL?
 * An SME will be needed to clarify this.
 * Electronic Service Information Object
 * Electronic Address is too generic as a datatype.
 * Definition depends on type of endpoint/transport protocol that needs to be addressed, including: E-mail (definite), http (definite), SOAP, RESP, mllp (possible), x12 (possible)
 * Action Item: Work on this object offline.
 * Bob and Karen will lead this discussion, starting 10AM on Monday.
 * Need a Webex session to be arranged. Support team will look into this.
 * Response Data Set
 * General
 * For definitions like “See Telephone Object” or “See Certification,” please refer to the appropriate entry in the in the Response Data Set spreadsheet. The instance in the response data set exists to demonstrate that this data element could occur more than once (i.e. to imply multiplicity).
 * Organization
 * Organizational Record Status
 * Use HPD record status of “active” and “inactive.”
 * Organization Type
 * If NPIs’ multiplicity is ‘multiple’, then an Organization Type should also have the capability to be multiple instead of single.
 * There is a limited list of Organization Types coming from taxonomy code set so that each organization should pick which type is fitting for their particular use from this list (these lists exist in ISO and Healthcare Taxonomy Codesets). Need to choose between ISO or healthcare taxonomy code lists.
 * Action Item and Note: Organization Type to be left as yellow and researched (ISO and healthcare taxonomy codesets being researched offline by Karen and Bob) as it is difficult to decide whether ‘Organization Type’ should be single or multiple without knowing the particular taxonomy codesets.
 * Individual
 * Individual Record Status
 * Question: Can we reasonably expect to know values other than “active” and “inactive,” such as “deceased” or “retired”, the other HPD status values?
 * “Retired” and “deceased” would be very valuable for pulling. From a fraud perspective, knowing when an individual provider is deceased is critical.
 * Decision: Include all HPD status values.
 * Individual NPI
 * The intention of an NPI is to only have one per provider however this may not be the case in practice.
 * Action Item and Note: Explore current standard for issuance and resolution of multiple NPIs for an individual.
 * Individual Provider Type
 * Decision: Research ISO 21298 code for specialty in relation to Individual Provider Type.
 * Action Item: Leave Individual Provider Type as ‘multiple’ for now and resolve code sets offline.
 * Individual Gender
 * Question: Is “M,” “F,” and “U” sufficient?
 * Concern expressed regarding differences between ‘unidentified’ and ‘not specified.’
 * In HL7, there is a null-type for ‘not specified.’
 * ISO dataset is limited to “M” and “F.”
 * Action Item: Limit values to ISO values of “M” and “F.”
 * Provider Directory ID/Reference
 * Provider Directory ID changed to ‘Provider Directory Reference.’
 * The need exists for a mixed-mode environment that has additional capability for the identification of the fact that there are multiple occurrences of directories.
 * Question: Are two Data Elements necessary? Will there be a unique reference and a name?
 * If there are multiple directories, it may be necessary to have a data element that tracks which one provides an answer. This element provides this capability.
 * LDAP implementations inherently include this capability.
 * In LDAP, each directory controls an arm of the larger namespace so that every element is a namespace. The name of the element implies which directory the element was discovered in.
 * This is not the correct way to achieve this. If a provider other than LDAP implements this, it will not function.
 * Action Item: For time being, element will be left in data set and discussed in further detail later.
 * Organization – Organization Relationship & Individual – Organization Relationship
 * Both sets will be discussed offline.