Provider Directories (PD) S&I Framework Initiative

1. Provider Directories (PD) S&I Framework Initiative Summary of Key Findings from Pre-Discovery Stakeholder Interviews May 27, 2011

2. Areas Explored during Stakeholder Interviews • Definitions of Individual Provider, Entity/Organization, Service Directories, Routing • Ambiguities in the Identities of Individual providers and entities • Architecture to Support Nationwide Discoverability and Routing of Information from Provider Directories • Adoption Level and Evaluation of Existing Standards • Policy Issues and Questions • Feedback on Initiative Challenge, Scope, Target Outcomes, and Timeline • Other Findings NOTE: The contents within this document capture themes of views, concerns, and thoughts shared by multiple stakeholders during interviews conducted during the pre-discovery phase of this Initiative. This is not intended as a detailed analysis of any topic areas above by the S&I Framework.

3. Definitions of Individual Provider, Entity/Organization, Service Directories, RoutingAmbiguities in the Identities of Individual providers and entitiesArchitecture to Support Nationwide Discoverability and Routing of Information from Provider Directories

4. Definitions of Individual Provider, Entities, Service Directories, & Routing • A provider directory includes entities such as legal organizations and individual providers who are licensed individuals that provide medical services or care within entities • Organizations have endpoints where data can be routed to. Each endpoint must be properly defined such as, site locations and also have information to support routing • Directories can also include delegates for providers such as an administrative person • Service directory is an effective locator for provider information that includes service information • Network service is not set out for everyone to discover, there has to be legal agreements to connect an interface • Routing simply involves a process of getting data from point A to point B • Information needed to enable routing is associated with organizations and implicit in the address of recipient (e.g. URL, IP address) • “Routing address” is not a common term, it needs further clarification. Preferred to be used as a verb “ to route” rather than a noun • Done by an underlying internet system like an ISP and therefore, out of scope • The focus should be on the acquisition of information from a directory to route data from the EHR to the intended recipient’s system i.e. “addressing” information • Finding attributes of an entity or individual is a search or query, not routing

5. Ambiguities in the Identities of Individual Providers and Entities • There is little or no ambiguity with legal entities • Some preference for using OID to identify entities • Ambiguities exist more among individual providers • In any given year, 20% of providers change address or phone number, 30% change health plans, 5% have licensing changes. • There is need for defining each individual and their relationship to the entity • There is need for both human intervention and automation to disambiguate identities of providers, especially those that work in multiple locations and for multiple entities • Need enough data to identify a particular provider • Ensuring that there is a mechanism to verify the identity of the recipient is critical • Use of unique identifier like NPI is preferred • This may include the provider registering to confirm or attest • This should be addressed in the initial registration and maintenance process • Discoverability would include getting 1) end point for entity and changes that have occurred, 2) verification that data are still valid for that organization, 3) verification that individual provider is associated with the entity • No matter which algorithm or matching system is used, one cannot reconcile all discrepancies. Therefore, an ongoing audit reconciliation process is needed

6. Architecture to Support Nationwide Discoverability & Routing of Information • A central directory may appear as an ideal technical solution, but multiple issues around maintenance, politics, governance, and others need to be resolved • Having a highly centralized mechanism is preferred • For example, a model with few (~2 or 3) centralized individual level provider directories as well as enterprise-level directories which are dependent on data from individual level directories • This model supports better reliability, accuracy, and integrity of data • A national registry of directories would be useful • DNS is distributed, but there is no authoritative source • Federated model is more practical • Reduces communication lines and vulnerability to outages • Use of local identifiers with a unique identifier in a national registry can have advantages for maintenance. • Keeps data closest to individuals who are trusted to provide/maintain data by members

7. Architecture to Support Nationwide Discoverability & Routing of Information • Directories have to reflect architecture of states, organizational structure, policies, and procedures • Providers do not care about a national or federated model, they just want to go one place to enter and access the information • Accreditation within a federated model is necessary. Each directory must manage its own directories and go through a validation process • Access to directories can be based on business relationships and will be limited by the community that owns the directory • One example of a model used outside the US is the Canada HealthInfoway, which has a provider directory. • Canada is using a federated model in each of the provinces and have found that registries needed to function together. • Canada also has a certification program

8. Adoption Level AND evaluation of Existing/emerging Standards

9. Perceived Advantages and Disadvantages of Existing/Emerging Standards • As part of pre-discovery, the team asked interviewees for their assessment of existing and emerging provider directory standards • There were divergent opinions which might be attributed to the context of the exchange framework being assumed • We note that the HITSC Privacy and Security WG also evaluated provider directory standards and found the same divergence of views when they presented their recommendation to the whole committee • HITSC P&S WG presentation attached at end of this slide deck • We have noted these divergent views and have attempted to address them in initial scoping and user stories

10. Perceived Advantages and Disadvantages of Existing/Emerging Standards (1)

11. Perceived Advantages and Disadvantages of Existing and Emerging Standards (2)

12. Perceived Advantages and Disadvantages of Existing/Emerging Standards (3)

13. Policy Issues and Questions

14. Policy Issues and Questions • If there is a national directory that deals with trust issue, how much value will be realized from using the directory? • In regards to privacy and security, how can one avoid publishing or discoverability of person who prefers not to be discovered or only wants part of information to be discovered? • There is a need to address ways that discoverability can be abused • The identification of individuals suggests need for a unique person identifier • It will be essential to address the relationships between entities and have protocols to support them

15. Policy Issues and Questions (continued) • The certification/accreditation of directories is critical including determining the vehicles that allow the federal government to certify provider directories. • At other levels, the issue of who can access or do certification (not at federal policy level policy, but maybe at state) • At the state level, the possibility of widely adopted directory design and ability for ONC to use policy/contract levers to support adoption • Determining an architecture to support this use case is important and should be defined with the use case • It will be difficult to determine how recommendations from this effort will get implemented given MU Stage 2 timing

16. Feedback on Initiative Challenge, Scope, Target Outcomes, and TimelineOther findings

17. Initiative Challenge presented during Pre-discovery Phase • In order to enable point-to-point or mediated health information exchange, senders and mediators of health information messages need a mechanism to determine a recipient’s address – such as Direct Address, IP Address, mailing address, phone/fax number, and service addresses (e.g. to support HL7 ORU).  Today, this functionality is enabled through other mechanisms, such as calling the provider via telephone and asking for his/her address, but a scalable and standardized solution will be needed in order to enable state-level and national health information exchange.

18. Feedback on Initiative Challenge • The general focus should be transitioning from a paper environment to electronic environment to discover information about providers through EHRs which cannot be done today • It is not clear why mediators of health information exchange would need a mechanism to determine a recipient’s address • The term “Mediate” is not clear. The focus should be enabling sending and searching for data, similar to the NwHIN efforts • It may drive people back to HIE, HIOs, or other robust models • The challenge is very Direct-oriented. It needs to include other areas like NwHIN, which have service registries • Setting the focus on routing already defines the minimum data elements a directory should include. • Getting to a scalable and standardized solution for state or national health information exchange depends on the entity that owns the directory • If the exchange is within the entity’s domain, then the routing is easier. But • If outside the domain, there is need for reconciling the data, either by itself or through another entity.

19. Feedback on Initiative Challenge - Specific Suggestions to Change Content • Exclude mention of “point to point” or “mediated” health information exchange, it should just be “health information exchange” • Replace some of the examples listed for a recipient’s address (i.e. mailing address, phone/fax number) with simply “internet service addresses” • Add “to support routing” after “service addresses” and delete (e.g. to support HL& ORU) • Exclude the phrase, “such as calling the provider via telephone and asking for his/her address” • Replace part of first sentence with “In order to enable sending and receiving health information content…” because it doesn’t matter whether an HIE or HISP is involved or how to use the information. The information is just needed for health information exchange

20. Initiative Scope presented during Pre-discovery Phase • This initiative in its first phase will address: on the transaction requirements and core data set to support EHR system queries to provider directories to obtain routing information that will enable electronic health information exchange. It will also support the development of certification criteria for EHRs to support provider directory messages. • This initiative in its first phase will not address: • Maintenance of provider directories. • Directories that are used internally in organizations or systems. • Exchanges between provider directories themselves. • Use of directories for purposes related to healthcare reimbursement

21. Feedback on Initiative Scope • The scope is a good starting point to get EHR vendors more involved as long as more work is done afterwards • The focus should be on getting provider attributes not just “routing information” • Providing “routing information” is not accurate. Obtaining the information about the location to route health data is more accurate • To support provider directory messages and messaging framework, different artifacts would be needed than what this Initiative intends to produce • If maintenance is not addressed now, there is a risk of coming up with an architecture that does not work • Keep maintenance related to trust in scope, no one will route if there is no trust.

22. Feedback on Initiative Scope (continued) • If the federated model is being considered strongly, then exchanges between provider directories would need to be addressed • “Healthcare reimbursement” needs to be clarified • There is no need to specify “use of providers for purposes related to healthcare reimbursement.” • If discovery of endpoints is the focus, there is no need to eliminate a particular payload • Given that the scope implies querying directory for every message, there may be a need to scope out to types of EHR systems like those supporting ASP vs. client-based • ASP-based EHR systems could deal with constant queries, but perhaps others may find it difficult to manage volume of queries sent out

23. Initiative Target Outcomes presented during Pre-discovery Phase • Providers and other authorized, relevant entities can look up e-addresses online for the intended recipient. • Standards-based structure and query mechanism for Provider Directories that can be adopted by  EHR vendors, State HIEs, HISPs and other mediators of exchange to enable health information exchange in 2011 • Simplification of EHR vendor implementation of interfaces to provider directories

24. Feedback on Initiative Target Outcomes • Outcomes are too restrictive, a provider can look up more than e-addresses • Outcomes are vendor-centric, and it is not clear if ONC should be worried about simplification of EHR vendor implementation • Vendors can address this on their own • There is no current EHR vendor implementation of interfaces to provider directories, so it is not clear how to simplify. • The outcome statement needs rewording. • Clarify first outcome to indicate that providers and other entities can look up addresses through their EHR and not online • Delete comma and “relevant” from first target outcome • On first outcome, change “e-addresses” to “service addresses to support routing” • Update second outcome to read “Standardized query mechanism…”

25. Initiative Timeline presented during Pre-discovery Phase • By end of June, develop a use case and identify standard(s) to support EHR query of provider directories to obtain routing addresses. The standard(s) will be considered for addition into the Final Rule for Meaningful Use Stage 2. This will constitute an initial phase of work, while other phases will follow based on the needs of the community.

26. Feedback on Initiative Timeline • Timeline appears very aggressive even for the limited scope • The timeline may be difficult in terms of reaching consensus • Timeline would be more realistic if the issue of federating multiple directories is not addressed • Timeline is aggressive but possible if leveraging what already exists • An ambitious timeline, but important effort to complete • Once the initiative starts, then it will be clear whether the timeline can be met

27. Other Findings • The scenario for the use case involves a provider search with the name or other information for another provider to discover the true person, once the person is discovered, then the EHR system should be able to seamlessly route data to the recipient • Providers do not want to know much about security, they believe the EHR system should handle that. • Coordinate with and leverage work of Community of Practice, currently working on a minimum set of data elements for provider directories

28. HITSC Privacy & Security Workgroup Recommendations APPENDIX

29. HIT Standards CommitteePrivacy and Security WorkgroupRecommendations for Electronic Health Record (EHR) Query of Provider Directories Dixie Baker, Chair Walter Suarez, Co-Chair May 18, 2011

30. Privacy and Security Workgroup Dixie Baker, SAIC John Blair, Taconic Anne Castro, BlueCross BlueShield of South Carolina Aneesh Chopra, Federal Chief Technology Officer Mike Davis, Veterans Health Administration Lisa Gallagher, HIMSS Ed Larsen David McCallie, Cerner Corporation John Moehrke, General Electric Steve Findlay, Consumers Union Jeff Jonas, IBM Wes Rishel, Gartner Walter Suarez, Kaiser Permanente Sharon Terry, Genetic Alliance

31. Needs Identified by HIT Policy Committee • Identified need for consistent approach to cross-organizational provider directories to support the exchange of health information • September 2010 Testimony resulted in narrowing of focus to: • Interoperability among existing directories (no “rip and replace”) • Interoperability between EHRs and provider directories: Capability for EHR’s to query national (federated) enterprise-level provider directory • Central need: Capability to search for and find “discoverable” information essential for enabling exchange of health information between enterprises • Enterprise-level provider directory (ELPD) content should be limited to: • Basic entity information (e.g., name, address, human point-of-contact) • Externally accessible information exchange services (e.g., domains, message protocols, transport protocols, “inbox” locations) • Security credentials

32. Two-Phased Approach for Developing Recommendations for Provider Directory Standards • To meet immediate need for standards to support Stage 2 EHR certification, recommend standards, implementation specifications, and certification criteria for EHR query of enterprise-level provider directories • Recommendations presented today • Develop recommendations for Enterprise-Level and Individual-Level Provider Directories in concert to address needs identified by the HIT Policy Committee • Recommendations for Enterprise-Level Provider Directories received in February 2011 • HITPC approved Information Exchange Workgroup’s recommendations for Individual-Level Provider Directories May 11, 2011

33. Standards Requirements

34. Public Testimony Received to Date by the P&S WG • NwHIN requirements for directory services • Direct Project • Exchange • Veterans Health Administration • HIEs • Department of Vermont Health Access • New England Healthcare Exchange Network (NEHEN) • Standards • Integrating the Healthcare Enterprise (IHE) Healthcare Provider Directory (HPD) Profile and Social Security Administration (SSA) experience with IHE HPD • ASC X12 Provider Directory transaction • HL7/OMG’s collaborative effort on the Healthcare and Community Services Provider Directory (HCSPD)

35. Scope of Current Recommendation • Standards, implementation specifications, and certification criteria to support Stage 2 meaningful-use of EHRs to query enterprise-level provider directories • Standards and implementation specifications needed: • Schema • Vocabulary • Transport • Query Language • Certification functionality needed: • Search for and discover entity (i.e., search => list => select) • Search for and discover services entity offers for exchanging information with other entities (including entity’s URL or electronic address to receive information) • Search for and discover entity’s security credential

36. Current NwHIN Standards 1 While the LDAP family of standards does not explicitly address identity federation, multiple strategies exist for federating LDAP directories. Because DNS is inherently federated, the Direct Project chose to use it for credential discovery, while recognizing that an LDAP approach would be a more complete solution.

37. Schema, Content, Transport, and Query Standards

38. Functionality Supported 1 Individual-Level Provider Directories are outside the scope of the current task, but need to be anticipated

39. Recommended Standards, Implementation Specifications, and Certification Criteria 1 The Standards and Interoperability Framework team should select either REST or SOAP, as most appropriate within the context of the NwHIN standards currently being defined. 2 To support LDAP federation, a profile specifying a standardized way to federate LDAP directories is needed.