ONC Provider Directory Community of Practice

1. ONC Provider Directory Community of Practice January 18, 2012

2. AGENDA • Overview of the Guide • Populating the Provider Directory • Maintaining the Provider Directory • Appendices

3. Purpose: A Practical Guide This guide is being developed under the direction of the Provider Directory COP to provider a ready reference tool for HIOs planning or implementing provider directory services: • The specific focus is on populating and maintaining provider directories • It is not designed to be a comprehensive guide or a technical implementation guide The scope of the effort focuses on insights and lessons learned from current activities across the country • Identify relevant provider directory efforts and assess key practical issues confronted in populating and maintaining directories • Provide practical guidance on how to approach barriers in these areas Objectives for today • Get feedback on current draft of “Practical Guide to Populating and Maintaining Provider Directories”

4. “Practical Guide to Populating and Maintaining Provider Directories for Health Information Exchange” Designed to provide guidance and support to organizations looking to establish a provider directory to support health information exchange Input gathered from • Interviews with leaders of several active state HIEs and provider directory vendors • Materials developed by the “Data Populating Workgroup” as part of the ongoing work of the ONC Community of Practice for Provider Directories

5. Matrix of relevant provider directory efforts: HIOs

6. Matrix of relevant provider directory efforts: Vendors

7. “Practical Guide to Populating and Maintaining Provider Directories for Health Information Exchange”:Table of Contents • POPULATING THE PROVIDER DIRECTORY • Define the relevant Use Cases • Determine which providers and associated entities to include • Determine which data elements are required • Determine level of validity/reliability/precision required • Ensure policies and procedures are developed and in place • Select data sources for the Provider Directory • Determine the role of the HIE vendor (if applicable) • Import, merge, validate and publish data • MAINTAINING THE PROVIDER DIRECTORY • Establish a strategy for content maintenance and updates • Determine frequency and approach to update the Provider Directory • Determine funding sources and funding mechanisms • Develop approach to interoperating with other Provider Directories and HIEs

8. Table of Contents (cont.) • APPENDICES • Interview Guide for HIEs • Interview Guide for Vendors/Data Sources • Case Study: HealthBridge • Case Study: Vermont • Case Study: Wisconsin Medical Society • Interview Notes: Florida HIE • Interview Notes: CAQH • Interview Notes: Availity • Interview Notes: IBM Initiate • Provider Directory Interviewee Characteristics • Provider Directory Source Matrix v 04

9. AGENDA • Overview of the Guide • Populating the Provider Directory • Maintaining the Provider Directory • Appendices

10. Define the relevant Use Cases for the PD • Considerations • The two most common use cases utilized by HIEs are: 1) to provide • Two most common use cases utilized by HIEs are • to provide unambiguous electronic addresses of message/transaction senders and receivers • to make available security credential information (digital certificate and/or public key discoverability) • Additional use cases: • ad hoc human lookup of physical addresses (street address, city, state, etc), specialties, etc. • public health use cases, health plan use cases, credentialing, etc Every additional use case imposes additional requirements on what the provider directory must contain and how intensively it must be maintained.

11. Define the relevant Use Cases for the PD • The Standards and Interoperability (S&I) Framework Provider Directories Initiative Workgroup will eventually provide a foundation for HIO efforts • Collaborative process for implementation guidance • http://wiki.siframework.org/Provider+Directories • Currently focusing on two work streams: • Use Case 1 - Certificate discovery for Direct Project with a known Direct Address • Use Case 2 - Electronic Service Information discovery (including Electronic Addresses) with some known basic provider attributes • Data model to support these use cases has been finalized • S&I framework use cases have some overlap with core HIE use case requirements • Assumes that Direct Address is already known (but does not address how to make such addresses known) • Focuses on data elements for electronic service information discovery (but does not address other data elements that might be important to HIOs)

12. Define the relevant Use Cases for the PD Challenges Understanding the incremental cost associated with both building the provider directory (one-time costs) and maintaining it (ongoing costs) Additional use cases require the inclusion of additional data elements (centralized credentialing, Health Insurance Exchanges (HIX) public health registries, quality analysis, prescription drug monitoring programs and emergency notification systems, etc)

13. Define the relevant Use Cases for the PD Potential Solutions Carefully consider the range of uses for the provider directory and determine which specific use cases meet their near and long-term needs Ensure that the incremental benefits of expanded provider directories are equal to or greater than the incremental costs of building and maintaining the expanded features and data Focus on streamlining development of the provider directory based on current needs, while planning for the future “Keep it simple; think big, but start small; recommend standards as minimal as possible to support the business goal and then build as you go.” HIT Standards Committee

14. Define the relevant Use Cases for the PD • Example • The state of Vermont is creating a comprehensive state-level provider directory to be used by VITL (Vermont’s state HIE) and other Vermont state entities, collectively known as the “Vermont Health Services Enterprise.” • Enterprise includes: • VITL • the new Medicaid eligibility and enrollment systems • public health registries • health insurance exchange (HIX) • components of the state Medicaid Management Information Systems (MMIS) • The provider directory will be the authoritative source for the entire state.

15. Determine the role of the PD in the trust framework • Considerations • Two elements required to establish trust: • Validating that information submitted by the individual is accurate (information is correct) • Identity proofing, confirming that the validated information belongs to the individual registering (“I am who I say I am”)

16. Determine the role of the PD in the trust framework • I. Publish with no third party validation • Providers publish information to the directory with no validation of the information (similar to Facebook) • At the low end of the trust framework • Unlikely to be used in healthcare due to existing privacy and security requirements • Example • Completely open directory where anyone could self-publish their information • No validation of the information is provided. • Key considerations • This approach allows you to get started rapidly and is low cost. (if your objective is to just to make available a human readable directory, like a phone book) • Participants have no basis for trusting entries in the directory as no validation or ID proofing is done. • Potential for various data quality problems including duplicate or misrepresented entries on a single provider or organization

17. Determine the role of the PD in the trust framework • II. Validate subset of elements combined with identify proofing • Certain data elements provided by a participant during registration are validated using third party data sources (information is correct) • Validation of information submitted needs to be combined with an approach to ID proofing (“I am who I say I am”) • Example: To register for Direct Secure Messaging (DSM) service for Florida HIE, providers must provide their NPI and Florida licensure number • provider’s NPI is checked against the NPPES • Florida HIE sends a code to the FAX number associated with the provided NPI in NPPES • individual must enter the code they received via fax into system • individual’s license number is checked against the state licensure database • if license number matches, the provider is then notified via email they have been approved.

18. Determine the role of the PD in the trust framework • Key considerations • Provides validation of individual data element but needs to be combined with an approach that addresses ID proofing • Provider is rejected if there is conflict with any information presented or with third party data sources used to validate data elements

19. Determine the role of the PD in the trust framework • III. Validity score • After a provider registers with the directory, the information entered is validated against multiple data sources • A score is calculated based on the number of data elements entered by the provider that match information in the data sources • Example • PD checks data elements given by a provider during registration, such as state license number, NPI, address and phone number, against multiple data sources • All of the data sources contain the same information that was given at registration for three of the data elements: license number, NPI and address; however, the phone number only matches in three of the four data sources • Based on policies established by the PD, the information obtains a validity score above the minimum required to validate information given • A separate step is still needed to do ID proofing of the provider  

20. Determine the role of the PD in the trust framework • Key considerations • Information validated against multiple sources and allows for variability in data from different sources; differs from validating a subset of data elements (II) - a single data element that doesn’t match with a validating data source will eliminate the provider • Must establish policies up front for how the validity score will be calculated and what the minimum requirements are for a provider entry to be considered valid • Must establish policies to address inconsistent information from data sources; e.g. are providers allowed go to the data sources and update information that is out-of-date and register again? • Establish policies for how to deal with providers whose scores fall below the minimum validity score established by the PD

21. Determine the role of the PD in the trust framework • IV. Organizational certification • Relies on the certification of individual participants and end points by an organization (i.e. a hospital or health system) to enter them into the directory • Organization must have policies and procedures for validating and maintaining individuals and end points • Organizations required to have certificates (therefore undergoing ID proofing and validation) but individuals would not have to have certificates • Example • Hospitals participating in HIEs provide demographic and identifying information from their provider credentialing system • Specifications are provided for the content and format for the information • Information is considered to be valid from this source and is not subject to additional validation • Data sharing agreement and business associates agreement are signed between the facility and the HIE • Information is provided to the HIE by the authorized personnel who manage the hospitals credentialing system.

22. Determine the role of the PD in the trust framework • Key considerations • PD populated in a fairly quick and easy manner • Organizations like hospitals already have requirements and strong business incentives for validating and maintaining accurate information on their participating providers • Distributes the responsibility for identity proofing across organizations and reduces the direct burden on the PD to do identity proofing • Not a comprehensive solution for all providers (i.e. small provider offices do not fit under this model)

23. Determine the role of the PD in the trust framework • V. Full endpoint certification • Every participant and end point in the directory (organizations and individuals) is validated and undergoes ID proofing • Validation and ID proofing can be done by the provider directory or another organization (i.e. certificate authorities, hospitals, health systems or other trusted entities) • PD establishes the baseline requirements for validation and ID proofing • Could require every provider and organization in the directory to have a digital certificate: PD establishes the baseline requirements for ID proofing and validation of participants to become certified and receive a digital certificate • Authority to certify and issue a digital certificate can be delegated to a single or multiple third parties (i.e. certificate authorities, hospitals, health systems or other trusted entities) or can be centrally operated by the PD

24. Determine the role of the PD in the trust framework • Example • Colorado First Responder Authentication Credential Standard: first responders need to move and communicate easily across jurisdictions in the event of a terrorist or other all-hazards incident. Issuing credentials to first responders that comply with federal standards facilitates movement across jurisdictional boundaries, allowing more rapid response to a catastrophic event. • In-person identity proofing and background checks completed by Colorado departments or agencies • Identity cards issued that contain digital certificates and biometric information for a high degree of confidence in responder identity • Key considerations • Provides the highest degree of trust that can be achieved but comes with high cost and complexity to implement and maintain • Enabling the high level of trust gives participants comfort in using the provider directory to exchange health information • Key decision point re: how to structure the certification process - determine which entity does certification process (could be a shared responsibility)

25. Determine which providers and associated entities will be included in the Provider Directory • Considerations • Depending on the HIE’s use cases, the provider directory may include: • Entities only • Physicians only • Physicians, plus other clinician types • Entities associated with each physician • Challenges • Most providers have several affiliations and practice locations • Providers frequently change affiliations; the entities with which they are associated may change ownership or management • Individual and entity level provider directories may be set up in different databases, making it harder to coordinate both the initial build and the frequent updates to the provider directory Mapping individual–to-entity level relationships for individual providers is a high-intensity on-going activity.

26. Determine which providers and associated entities will be included in the Provider Directory • Potential Solutions • Include only providers and associated entities required for current use cases, while planning for future growth • The final grouping of addresses and identification of entities and entity relationships will almost certainly require ongoing manual intervention for the near future • Insights • Carefully determine which providers must be included in provider directory. • Determine which providers will be needed in the HIE and/or will provide added value for HIE exchange and target them for early participation and registration. “It’s better to have completely accurate information on the active providers in the HIE than inaccurate information on many providers, not all of which are active users of the HIE.”

27. Determine which data elements are required Considerations A high level of accuracy (~ 99%) typically required for the exchange of clinical information Lower accuracy levels may be accepted if PD is also used for purposes such as provider look-up If PD also used outside of the HIE for other purposes such as claims payment or credentialing, the level of accuracy needed may vary May be variation in accuracy needed for specific data elements Challenges Manual intervention ensures greater accuracy but adds cost to populating and maintaining the PD

28. Determine which data elements are required Cost of data acquisition and maintenance 100% Level of accuracy required

29. Determine which data elements are required HIEs/states using or planning to use a variety of sources: • Participating entity directories • State medical licensing boards • State licensing boards for other medical professions • Multi-payer claims databases • RECs, especially for accurate addresses • NPPES (CMS) for NPIs • Content providers: labs, hospitals • AMA • Google, etc. • Vendors typically rely on fewer, targeted data sources to populate commercial PDs: • Payer databases • Third party data feeds from commercial vendors (e.g. Health Market Sciences) Vendors interviewed rely primarily on their data sources to manually validate information directly with providers Vendors occasionally validate directly with providers via call centers and field reps: goal is to streamline and cut costs by eliminating this step (and downsizing or eliminating call centers) All HIEs interviewed always validate information directly with providers by phone or in-person visit

30. Determine which data elements are required • Potential Solutions • To achieve nearly 100% accuracy, manual intervention is essential to creating and populating PDs • Budget for the critical tasks associated with achieving a degree of data accuracy appropriate to the purpose being served • Insights • Adequately fund and staff the PD project to carry out the tasks associated with a high degree of data accuracy

31. Ensure policies and procedures are developed and in place • Considerations: • Prior to launching the PD, HIEs should establish policies and procedures for the PD: • Authorization: determine who has the right to access the provider directory • Authentication: verify that an individual who has been authorized and is seeking to access information is who he or she claims to be (identity proofing) • Two-factor authentication is most common among interviewees • Access: governs when and how a patient’s information may be accessed by individuals • Only HIE staff or HIE’s vendors have complete access to PD; providers have limited access for look-up and routing purposes • Most PDs are not published or publically available • HealthBridge: only providers that provide data receive access rights to PD • Audit: record and examine when information is accessed and by whom

32. Ensure policies and procedures are developed and in place • Considerations (cont): • Additional policy and governance issues: • Who can change/modify data elements • Who can access the provider directory (only HIE staff, all sites that provide data for the provider directory, etc.) • How certificates and certificate expiration be handled • Will the provider directory become a source of revenue • Will the HIE provider directory be used by other entities

33. Ensure policies and procedures are developed and in place • Challenges • Time-consuming process • A multi-stakeholder and collaborative approach is optimal but may be challenging and cumbersome • Agreements for use of the PD must be developed and implemented, and may be costly • Potential Solutions • Early investment is critical and saves time/money in the long run • Anticipate and budget for legal assistance to create policies and to help determine what agreements are needed • Insights • Allow ample time for development of policies, procedures and agreements for use of the HIE PD • Legal assistance should be considered a necessary cost of doing business

34. Select data sources for the Provider Directory • Considerations: • HIEs must understand the capabilities and limitations of the data sources: • What data elements are available? • What data elements are missing or unavailable? • What is the original source of the data (provider, provider representative (office administrator), payer claim files, designated entity, licensing database, etc.) • How accurate is the data? • How frequently is the data updated by the data source? • What specific fields are updated by the data source? • Who are the primary customers for this data source? • What data formats are available for initial feed and ongoing maintenance? (batch, real-time) • What is the associated cost of the data? • How trustworthy is the data (what is the ‘trust framework’ of the data source)?

35. Select data sources for the Provider Directory • Considerations (cont): • Common data sources include: • Providers • Labs/hospitals • Medical Licensing and registration boards • Credentialing databases, both local and national (e.g. CAQH) • Multi-payer provider claims databases (e.g. Availity) • NPI (NPPES) • PECOS (Medicare Provider Enrollment, Chain, and Ownership System) • Medical practice boards • Medicaid and Medicare all payer claims databases • State Medicaid Management Information Systems files (MMIS) • State multi-payer claims databases (standard APCDs have a limitations of 3 hierarchy fields for provider affiliations) • RECs (for current addresses) • AMA provider files

36. Select data sources for the Provider Directory • Challenges: • Most data sources are created for purposes other than populating PDs • Data sources may contain hundreds of data elements that are not required in the PD • Data sources may update their data infrequently or at different rates (e.g. annually for credentialing databases, quarterly for payer claims databases) • Higher costs associated with using multiple data sources (costs for various data sources, costs for staff required to manage data sources, normalize, merge and reconcile data, etc.) • Large national databases cannot maintain accurate hierarchies for providers (e.g. individual to entity relationships)

37. Select data sources for the Provider Directory Pros of using vendor PDs Cons of using vendor PDs • HIEs could save time and money by streamlining process of creating and populating their own PD • Vendors have resources to use sophisticated automation tools for creating, reconciling and maintaining data, so HIEs may not need to purchase PD their own ‘tools’ to manage PD • PDs are large and widely used, which promotes data accuracy • Vendor PDs are national, so perceived as less accurate and/or unreliable compared to local data sources • Vendor PDs created for different purposes than HIEs (e.g. credentialing) so data elements may be missing or out of date • Less formalized synchronization between multiple payer databases (data sources), so risk of duplicates or faulty information is higher • Difficult to maintain accurate hierarchies for providers: individual to entity relationships

38. Select data sources for the Provider Directory • Challenges • Must balance the costs and efficiencies of using outside data sources with the other approaches such as provider “self-registration” • Data is not always accurate and is difficult to validate • Data sources do not update their information frequently enough for purposes of the PD • Insights • Providers themselves are often the best source of truth • PDs may be able to re-purpose their data for other state or local entities that require PDs, such as MMIS and the federal insurance exchanges

39. Determine the role of the HIE vendor (if applicable) • Considerations • HIE vendors have their own tools and technologies available to create the provider directory, or will partner with a provider directory vendor for this purpose (e.g. IBM Initiate, Oracle) • HIEs can leverage the vendor tools, resources and partners to create, populate and manage the PD • HIE can utilize an existing state-wide PD if available • Example: a State Master Provider Directory being developed by the state of Vermont, which will be used by the entire “Vermont Health Enterprise”. This enterprise includes the Vermont Agency of Human Services (AHS) shared services such as the eMPI and Master Provider Directory, the Health Insurance Exchange, the new Medicaid Eligibility and Enrollment systems, Public Health registries and MMIS MITA (State Medicaid Management Information Systems and Medicaid IT Architecture) components. 

40. Determine the role of the HIE vendor (if applicable) • Challenges • PD is typically a central point of integration in the HIE architecture and may be impacted by changes made to surrounding HIE technologies • Strong project management is needed to successfully coordinate changes in the HIE and/or in vendor products that may impact the PD • Manual intervention likely required to ensure a high degree of data accuracy Potential Solutions • HIEs should work closely with their HIE vendor to coordinate outside technologies, tools and resources • HealthBridge implementing Initiate product to increase efficiencies and manage growth in PD • Determine approach to establish a strong trust framework for the PD and work with HIE vendor to actualize the trust framework

41. Determine the role of the HIE vendor (if applicable) Potential Solutions (cont) • May be able to lower costs by using internal staff to customize the PD and manage vendor software • HealthBridge uses Axolotl but does a lot of custom programming to maintain system; lowers costs to use own resources (does not pay Axolotl for programming) • Insights • Closely monitor vendor involvement with the development of the PD to ensure it meets HIE requirements for a trust framework and follows HIE policies and procedures

42. Import, merge, validate and publish data Considerations • Determine optimal approach to populating the PD, based on use cases • Provider data directly from providers is more labor-intensive but may provide more accurate data, especially for provider affiliations and hierarchies • Importing and merging of data from disparate data sources requires some manual intervention to ensure the data is accurate and current • Database tools may streamline the process of creating and modifying databases Challenges • Establishing and automatically updating one-to-many relationships is challenging. • Standards are not mature and are not used consistently • “We start with standards then create our own”, Availity • Information may be set up in different databases with different architectures, making it harder to coordinate frequent updates • Data sources have their own unique naming and numbering schema

43. Import, merge, validate and publish data • Potential Solutions • The use of manual intervention is key • Some automation tools may be helpful to build the PD and validate information • PD design should be flexible enough to accommodate hierarchical information and future growth • Standards for PDs should be used as they become available • All interviewees acknowledged that development and finalization of standards is very important, but current lack of standards is not slowing down their business activity • Question of whether federal insurance exchange efforts will accelerate efforts to develop standards for PDs • Insights • Be diligent about data accuracy; there is no substitute for manual review and intervention. “Be patient! It’s a daunting challenge to get it right.” Hunt Blair, Vermont

44. AGENDA • Overview of the Guide • Populating the Provider Directory • Maintaining the Provider Directory • Appendices

45. Establish a strategy for content maintenance and updates Considerations • Content may be updated in a variety of ways: • Content providers (e.g. labs and hospitals) send address books to the HIE to perform a one-by-one comparison of every provider • Allows validation of the provider’s affiliations with each hospital, lab, etc. • HIEs obtain regular or just-in-time downloads from key data sources • As data sources acquire new information on providers, they may pass along known changes in either real-time or in batch modes • New providers are identified when they enter a community and are asked to ‘register’ with the PD • Initial registration may be accomplished through a provider portal or with provider relations staff • HIEs learn of changes to provider data as their data sources add/delete and update data

46. Establish a strategy for content maintenance and updates • Challenges • HIEs may not be aware of new providers in the community • Data sources may be updated on an infrequent basis, limiting their usefulness for PDs • Potential Solutions • Obtain regular downloads from their chosen data sources • Scrub data against data in the existing PD to identify new records: • Actively reach out to new providers in the community • Regularly confirm existing information on providers in the directory • Leverage information from RECs - an excellent source of provider information, due to the frequent ongoing contact by REC staff • Insights • Formally designate staff to update and maintain the PD • All HIEs interviewed have 1 – 2 FTEs dedicated to maintenance

47. Determine frequency and approach to update the Provider Directory • Considerations • Data accuracy can be optimized by designating staff to track changes from providers and data sources • HIEs should be aware of the frequency associated with updates done by their data sources, and plan to augment, as needed • A smaller data set is easier to maintain • Active maintenance of provider affiliations is critical • Challenges • Real-time updates are not available from most data sources • Data sources provide updates at different intervals and in a variety of formats • Manual intervention is important to maintaining a high degree of accuracy but may be costly

48. Determine frequency and approach to update the Provider Directory • Potential Solutions • Use manual intervention and/or automated tools to compare and reconcile data based on specific criteria • Designate and budget for staff to perform necessary updates • Create and enforce policies and procedures regarding frequency of updates • Establish inactivity reports/ticklers noting providers who have not opened results delivered to them in xx days, and follow-up with these providers • Send a report of active providers in PD to affiliated entities (data sources) for validation on regular basis (daily, weekly, monthly) • Rely on local data sources (providers, hospitals, RECs) to validate information – local information may be more reliable than national database • Contact the practice directly to validate information, as needed. • Develop in-house expertise to manage tools and PD software, as possible • Insights • Seek ways to streamline systems, lower costs and avoid unnecessary intervention.

49. Determine funding sources and funding mechanisms • Considerations • Funding sources for PD development and maintenance include: • Federal/state sources (HITECH)/public • Subscription fees • Transaction fees • Grants • Public assessment fee on claims • Transfer of funds from different state agencies to support a centralized provider directory • Consolidation of duplicative services in state agencies (e.g. medical licensure, health insurance exchanges, public health, etc.) • PD may be leveraged across multi-state initiatives, to contribute to economies of scale and a more favorable ROI • Vendor funding is more robust than HIE PD funding

50. Determine funding sources and funding mechanisms • Challenges • PDs are a necessary cost of doing business • Potential Solutions • Ensure the HIE provides clear value to providers and patients • Establish a solid ROI for provider participation in HIE • Consider using the PD for other purposes (i.e. a centralized or modular provider directory) to consolidate duplicative services in state agencies (i.e. Medicaid, HIX, public health, etc.) • Assess feasibility of multi-state initiatives, which offer economies of scale and potential new funding streams • Leverage structures already in place • “Medicaid has a monster set of redundant infrastructure”; community could benefit from using infrastructure already in place (Availity) • Expand value of PD by using analytics capabilities