In a previous post, we introduced four key fields critical to Directory data quality. One of these fields is the SERV_DESC field, which plays a vital role in flagging the purpose of a given Direct address, especially for workflow or organizational level addresses. In this post, we’ll discuss the importance of the SERV_DESC field, including how to use it to improve data quality and usability of the Directory.

The Importance of SERV_DESC Field

Historically, the community often resorted to unstructured embedding of the purpose within the Direct address itself (e.g., or populated fields reserved for Provider data (PROV_LAST_NAME = Radiology, PROV_FIRST_NAME = Department). These approaches lead to data cleanliness concerns, especially when synchronizing our Directory into FHIR resources. The SERV_DESC field addresses these concerns by providing a standardized way to flag the purpose of a given Direct address while helping us keep non-provider data out of Provider fields.

Current State

The vast majority of our Directory records do not contain a populated SERV_DESC value. As the Directory Data Quality Tiger Team reviewed the existing Directory fields, SERV_DESC was identified as having the ability to greatly improve data quality and usability of the Directory. DirectTrust is encouraging all Directory participants to populate this field when applicable, as it allows for more refined address searches that help senders hone in on the right recipient.

How to Use SERV_DESC and Which Records Should Have a Value

Any record in the Directory could have a valid SERV_DESC value (or more than one), but some are higher priority. Ideally, all workflow, departmental, or organizational level addresses should have their SERV_DESC value populated so users (and code) can better understand the address’s purpose and where to send a specific type of Direct Secure Message.

Benefits for Searching

A populated SERV_DESC value enables more efficient searches, allowing users to find specific recipients based on their purpose or the types of messages they’re willing and able to receive. Let’s say you wanted to find pediatricians in San Diego. Already well understood fields like the Provider’s specialty and location will work, but imagine if you could add a specific SERV_DESC to the same query? For example you could return a similar list of pediatricians in San Diego that support ‘referrals’. 

Additionally, you may not be looking for a provider but an organization or workflow address. A search on an organization might return a list of inboxes with various purposes like administration, medical records, or the cardiology department. If the organization has flagged those inboxes with an appropriate SERV_DESC, interoperability flows freely, ultimately leading to faster and more accurate health data exchange that positively impacts patient care.

Using the SERV_DESC Value Set

The existing value set for SERV_DESC  is fully extensible, which means new values can be added as needed. The Directory Data Quality Tiger Team collaborated with the National Directory of Healthcare Providers & Services (NDH) teams to create a unified level of scope and detail that will help align our Directory within the larger environment. The SERV_DESC Value Set is published on our website for access and use by any interested parties.


The SERV_DESC field is a crucial component for improving the Directory’s data quality and usability. By populating this field, the community can enhance searchability, interoperability, and ultimately the exchange of health data. The DirectTrust Aggregated Directory is one of the largest and most utilized address directories. To enable additional information exchange, we need help from the community to achieve our goal of at least every workflow or organization level Directory entry including data in the SERV_DESC field. As our Directory Improvement Initiative outlines, using the SERV_DESC field is a significant step toward faster and more accurate health data exchange that ultimately benefits patient care.

Learn more about the Directory Improvement Initiative and see prior blog posts here.

This post was contributed by Alex Young, DirectTrust Director of Technical Operations.