As part of our ongoing Directory Improvement Initiative, the Directory Data Quality Tiger Team recently identified four key fields in Directory address entry that can improve the quality of the DirectTrust Aggregated Directory. Learn more about the goals and timeline of the Directory Improvement Initiative (DII) in this previous post, as well as see an update on our progress in this post.

Confidence in the validity and accuracy of Direct addresses in the DirectTrust Directory is critical for making the most of Direct Secure Messaging. Directory users should be able to “know and trust” who they are exchanging health information with. The Directory’s growth is coupled with variation in address entry quality – entries may not contain all helpful identifying information or stray from best practices. At its core, the DII aims to streamline entry best practices and improve the overall quality of the Directory – but it’s not a “couple-day fix”.  Rather, it’s a long-term commitment to continuous improvement, validation, and verification necessary for a high-quality national Directory asset. An enhanced Directory expands the use of Direct, making it a more valuable data exchange option to benefit both patients and providers. 

Iteration through Continuous Improvement Cycles (CIC) is a large component of the Initiative. For the first CIC, the Directory Data Quality Tiger Team analyzed Directory entry fields, establishing best practices for data entry in each field. The Tiger Team outlined strategies for improvement for each field, including an implementation and review component. While reviewing all Address entry fields, four fields emerged as critical with room for improvement regarding compliance with entry best practices. If these four key fields improve, Directory quality and confidence will significantly improve.

Identifying the Four Key Fields for Directory Improvement

The four key fields with a significant impact on Directory quality include: 

  • Provider NPI (PROV_NPI)
  • Provider Specialty (PROV_SPEC_CODE & PROV_SPEC_TEXT)
  • Provider Fax (PROV_FAX)
  • Service Description (SERV_DESC)

Ensuring the vast majority of applicable Directory entries comply with best practices for each of these fields dramatically improves Directory quality. Each of these fields is important for identifying provider identity or address purpose. 

Three Types of Directory Entries

Before we outline why these fields are significant, it’s important to note that not all Directory entries require complying with the best practices for these fields. Why? Because there are different types of Directory entries.

The three types of Directory entries include:

  1. Affiliated Providers (most common)
  2. Workflow/organization level addresses
  3. Unaffiliated Providers (uncommon)

Directory Entry Type 1: Affiliated Providers

The most common type of Directory entry is what we call an “Affiliated Provider” – an individual  affiliated with an organization. We need to know identifying information about the provider and their associated organization. The table below outlines fields needed to describe both individual and organization qualities. In most cases, a “perfect” Affiliated Provider entry should contain all fields in the table aligned with best practices. 

If we want all fields for an Affiliated Provider populated, why not make them all required? While many of these fields are required by the system, some must be set to “required if known”. The latter is harder to enforce programmatically, which inevitably leads to important data being omitted. More on this later.

Directory Entry Type 2: Workflow/Organization Level Addresses

As Direct Secure Messaging has grown, so has the need for addresses that aren’t confined to a specific person. Enter Workflow/Organization addresses! These Direct addresses are used for either a specific purpose and workflow, or for an organization as a whole. Workflow/Organization addresses allow a team of people to receive a Direct message, mirroring how many health organizations work today.

Because these addresses are not specific to an individual, they have different requirements than the Affiliated Providers Directory entry type. Specifically, Workflow/Organization addresses require the “Describing Organizations” fields, not needing the “Describing Individuals” fields.

As interoperable health information exchange has grown, so have Workflow/Organization addresses. Improving the identifying information associated with them represents a huge opportunity to advance exchange even further.

Directory Entry Type 3: Unaffiliated Providers

Providers in this category are typically independent and not affiliated with an organization. Therefore, they need the identifying information of the “Describing Individuals” fields, but not all of the “Describing Organizations” fields.  This entry type is uncommon.

Directory address entries fall into the three categories above. Understanding their different field requirements helps us understand the impact of improving compliance with a given field’s best practice. The four key fields outlined below have varying impacts on all three types of entries.

Key Field 1: PROV_NPI – The Provider’s National Provider ID

The National Provider Identifier (NPI) field is arguably the most important field in the Directory. NPI is the core identifier for matching, discoverability, and association of providers who may be practicing across organizations. It’s also one of the most basic yet effective search functions in the new FHIR based query tools for the Directory. 

Unfortunately, the overall percentage of provider NPIs  populated across the Directory is lower than we hoped. The cause is likely that PROV_NPI must be set as a “required if known” field because not every individual in the Directory has an NPI, and not every entry in the Directory is for an individual. However, the vast majority of providers missing their NPI in the Directory actually do have an NPI which should be published. Our research indicates only about half of the 19 HISPs contributing data to our Aggregated Directory are publishing provider NPIs at the rate we hope to see. 

While it’s difficult for us to currently know the exact number of missing NPIs, we aim to tease this out by further distinguishing between Affiliated Provider and Workflow/Organization entry types in the future.  If we are able to immediately categorize an entry into an Affiliated Provider versus a Workflow/Organization category, we would know a more accurate accounting of entries that should contain an NPI. Keep reading for more on how we plan to distinguish these entry types as part of the DII. 

The bottom line? Any provider with an NPI should have their NPI published in the Directory (a “required if known” field). Improving compliance with this field will instill confidence in provider identity. This field is used by some vendors as a provider identity confirmation; some automated workflows will abort if the NPI is not populated or does not match. There’s a clear path forward to improve best practice compliance with this field and it comes with major impact.

Key Field 2: PROV_SPEC_CODE – The Provider’s Specialty 

Provider specialties are also “required if known” which means we are seeing some of the same issues with NPI. In general, only about half of eligible entries contain provider specialty information. Provider specialties act as another data point for assurance  a Direct message is sent to the right place. 

Additionally, specialty is also a standardized and reliable search parameter. At the DirectTrust/Civitas conference we demo some of the new FHIR-based search capabilities available to the Directory. If the provider specialty is populated, a search of “show me all pediatricians within 20 miles of San Diego” is possible. Furthermore, if the SERV_DESC field (outlined below) is also populated, a query of “show me all pediatricians within 20 miles of San Diego that also support 360x referrals” is possible. Finding and publishing the right specialty code is easy with a nationally established value set. Ideally, every provider entry in our Directory would have a PROV_SPEC_CODE  (again, “required if known”).

Key Field 3: PROV_FAX – The Provider’s Fax Number

Why are we talking about faxes in a Direct address Directory? Well, fax numbers can be a great bridge from legacy fax systems to Direct Secure Messaging. We know of vendors automatically routing faxes through Direct if they can match faxes with Direct addresses. I have also seen behind the curtain of many fax-based Directories of the past that are not only accurate but also have advanced workflows built around them. Imagine if the DirectTrust Aggregated Directory contained reliable fax numbers? Currently, a little more than half of the addresses that make up the Directory contain fax numbers. 

Key Field 4: “SERV_DESC” – The Address’s Purpose

Workflow/Organization addresses are often created for a specific purpose. Best utilizing these entries requires knowing the address’s purpose, but in the past, this hasn’t been easily identified in the Directory. The Tiger Team is emphasizing the SERV_DESC field’s opportunity as an existing but unused field as a place to identify purpose.

We can build a better Directory by developing a standard set of codes which act as a way to flag the purpose of any Direct Address. A few examples of address purposes the SERV_DESC codes may represent include:

  • Referrals
  • 360x referrals
  • Event Notifications
  • Submitting claims information
  • All or any Direct Secure Messaging

Once the initial value set is published, any Workflow/Organization level address should have the SERV_DESC field populated with its intended purpose. Previous guidance suggested that these address types use a workaround of using provider name fields to identify the purpose. (Ex: Lastname field: Radiology, Firstname field: Department). With the synchronization of the Directory to FHIR, we want to avoid pushing non-provider data into provider fields. The SERV_DESC field now fills the role of identifying the intended purpose for these addresses. Additionally, populating this field allows us to distinguish between Affiliated Provider and Workflow/Organization entry types, enabling more reporting.

Because this is a new purpose for an existing field, compliance with the Tiger Team’s established best practice is at 0%. We look forward to watching this field grow! 

The Report Card: Room for Improvement

Overall, improving the quality of data entry in the four key fields of PROV_NPI, PROV_SPEC_CODE, PROV_FAX, and SERV_DESC results in a stronger Directory. In future posts, we dig deeper into the potential of each of these fields, including their best practices. We’re publishing a “Report Card” of these four fields at their baseline so we can track improvement towards our goals. Through the DII we are encouraging vendors and HISPs to adopt and implement these entry best practices so all Directory users benefit. As we continue with CICs, we will publish additional Report Cards.

This post was contributed by Alex Young, DirectTrust Network Services Technical Project Manager.