The best practices in this post are outdated. For the most up-to-date recommendations, check out the Set Up Your Search Configuration for Healthcare guide.
Healthcare Best Practices Overview 
Hello Admins!
We wanted to consolidate all of our Healthcare 
best practices here for the benefit of all our users! Recent algorithm updates, like Orion, have changed the way we approach common Answers search configurations.
This post outlines best practices for your healthcare Answers configuration so that you can best align your config with the Answers algorithm and set your brand up for success. At the end of this post, we’ll provide tips for A) updating your existing configuration and B) applying the best practices to a new configuration with Solution Templates.
Configuration Best Practices (Backend) 
Below, we’ve listed our suggested Search Configuration approach for common Healthcare search use cases.
People Names
We previously prescribed best practices for searching people names when phraseMatch rolled out, and we still recommend the approach. When configuring people name search, you should always enable textSearch and phraseMatch on the Professionals vertical, like so:
"searchableFields": {
"lastName": {
"phraseMatch": true,
"textSearch": true
},
"firstName": {
"phraseMatch": true,
"textSearch": true
},
"name": {
"phraseMatch": true,
"textSearch": true
}
},
Configuring people names without NLP filters allows for much more flexibility in name searches, ensures that the most relevant doctors return to the top of the vertical, and reduces the likelihood that a user would see no results.
With our global algorithm improvements to people name searches, we’ll also default single-word queries (like “Lincoln”, for example, which could be a person or a place) to a person search, so the algorithm first checks if a person of that name exists before defaulting to a location search. If a person with the name doesn’t exist, we will continue to fall back to location. This should significantly reduce the amount of false positive location NLP filters applied to your experience.
Other Entity Names
Your brand’s Knowledge Graph likely contains other entity types such as Specialties, Conditions, and Locations. Aside from the FAQ entity type which has its own Semantic Text Search algorithm, all entity names should have the same configuration as people names. This will produce the best results and ensure that the most relevant results are shown at the top of a vertical. An example configuration is below:
"searchableFields": {
"name": {
"phraseMatch": true,
"textSearch": true
}
},
Lemmatization & Synonyms
Lemmatization
“Lemmatization” is the process of resolving words to their root forms - like understanding that “runner” and “running” are different forms of the same word. It’s critical in healthcare that we identify that words like “cardiology” and “cardiologist” are related.
Previously, we took a very conservative approach to lemmatization because it improved the precision of our results and reduced noise, which is usually something we aim for; however, it didn’t work as well for healthcare. To solve this problem, we’ve built our own custom lemmatizer that is healthcare-specific. Answers now uses a custom lemmatization for healthcare-related terms to ensure that all the different forms of medical terms are understood. Going forward, you will not have to add custom synonyms for words like “cardiologist” → “cardiology” or “radiologist” → “radiology”. The lemmatization will occur at an algorithm level and not at a configuration (or synonym) level.
Synonyms
For our healthcare experiences, we will be including an “out of the box” synonym library that will handle true healthcare synonyms and acronyms such as “OCD” → “Obsessive-Compulsive Disorder”. As you can imagine, there is quite a long list of potential healthcare synonyms. We’ve invested heavily in building our very own synonym library to improve the patient experience on Answers.
For now, these synonyms will be added to the Healthcare Solution Template and can be applied to your account at any time. We may change this approach in the coming months, so please be sure to check back for updates.
One Way vs. Two Way Synonyms
As an Admin, you may need to add business-specific synonyms to your configuration. In general, you should use one way synonyms, as they are more precise and are less likely to cause noise in search results. As an example, if you are considering adding “hospital” and “location” as a synonym of “healthcare facility”, you should map these as one way synonyms:
"synonyms": {
"oneWay": [
{
"phrase": "hospital",
"synonyms": [
"healthcare facility"
]
},
{
"phrase": "location",
"synonyms": [
"healthcare facility"
]
}
],
Stop Words
Stop words are commonly used words such as “and”, “the”, or “is”. The Answers algorithm has inherent stop word handling with its Natural Language Understanding. We also have a configuration object called additionalStopWords where an Admin can layer on business-specific stop words in the account. Our research into existing Healthcare Answers experiences revealed that there was an overuse of additionalStopWords where Admins were adding words such as “therapy”, “infection”, and “pediatric” to the configuration, leading to negative impacts on search quality.
Our new best practice is to only add the business name as additionalStopWords. If your brand’s business name is “Madison Health”, you can and should add “Madison” and “Health” as additionalStopWords. Layering in the business name as a stop word helps the algorithm unpack key tokens in the query and, consequently, help the patient find more relevant information.
Specialties and Conditions Treated - Yext Provided
You should continue to use our built-in Healthcare taxonomy in your experience. The taxonomy maps data from a healthcare entity’s specialty (i.e., “Cardiology”) to a list of generally-accepted procedures, conditions, and reasons for visit (i.e., “Heart Failure”).
The searchable field builtin.medicalSpecialty makes a healthcare entity’s specialty searchable.
Sepately, the builtinFile.medicalFacilityConditions_b and builtinFile.medicalCondition_b searchable fields map a Healthcare Professional’s and Healthcare Facility’s respective Yext category to the taxonomy.
Example configurations are below:
Locations:
"searchableFields": {
"builtin.medicalSpecialty": {
"nlpFilter": true
},
"builtinFile.medicalFacilityConditions_b": {
"nlpFilter": true
}
}
Providers:
"searchableFields": {
"builtin.medicalSpecialty": {
"nlpFilter": true
},
"builtinFile.medicalCondition_b": {
"nlpFilter": true
}
}
Specialties and Conditions Treated - Client Provided
A client may choose to provide its own list of specialties, conditions, procedures, or reasons for visit for its graph. This is permissible assuming that the client has a complete set of data for us to work with and search against. We recommend setting up entity types for each of the objects and linking them together in your Knowledge Graph.
To make the entity linkages searchable, you can leverage the linkedEntity.name searchable field through Text Search and Phrase Match. Example configuration below:
"searchableFields": {
"c_linkedSpecialty.name": {
"textSearch": true,
"phraseMatch": true,
},
"c_linkedProcedure.name": {
"textSearch": true,
"phraseMatch": true,
}
}
Exact City, State, and Zip Searches
Several healthcare partners have requested that if a user searches for a specific zip code, city, or state, the results are filtered down to only show results from within that place. For example, if a user searches “doctors in 10002”, the results would only show doctors in this zip code and none of the neighboring zip codes.
This can be accomplished by setting the field as an NLP filter. In the zip code example, the configuration would be as follows:
"searchableFields": {
"address.postalCode": {
"nlpFilter": true
}
}
Note: Make sure to use nlpFilterOrder and prioritize your place field in the JSON config. This will ensure that the exact matches are prioritized over the standard builtin.location searching.
List Fields: Insurances and Languages
A common healthcare query is “doctors who speak X language and treat Y condition”. The condition filter Y can be applied through the Yext built-in taxonomy or a Client-provided taxonomy. The language filter X, and any other profile list field such as Insurance Accepted, can be applied with Text Search. With the Spring ‘21 Release, we also have a brand new field highlighting formatter which will let the user know which values were matched from Text Search (see next section “Configuration Best Practices (Frontend)”.
An example backend configuration for lists is below:
"searchableFields": {
"languages": {
"textSearch": true
},
"insuranceAccepted": {
"textSearch": true
}
}
That concludes our config best practices section. Let’s go through a few frontend considerations…
Configuration Best Practices (Frontend) 
Below, we’ve listed out two frontend suggestions.
Text Highlighting (Text Search)
New with the Spring ‘21 Release, we have a Text Search highlighting formatter that shows the user which fields value tokens were matched to in the query. This will give the user more information as to why certain results were returned. You can follow the instructions in our feature Community Post to enable this in your Answers frontend.
For example, on your custom card, you can add this “Insurances Accepted mentions [[Insurance Name]]” text. It will render dynamically based on Text Search matches in a query:
Show Field Names (NLP Filters)
Within the Search UI SDK, there is a configuration option to show NLP Filter field names on a vertical.
Similar to the above highlighting for Text Search matches, we recommend adding showFieldNames to your frontend to help with NLP Filters usability and to give even more context as to why results are returning.
This can quickly be enabled in your index.json file by adding showFieldNames: true to your appliedFilters component:
"UniversalResults": {
"appliedFilters": {
"showFieldNames": true
}
}
In the example “cardiologist who takes Aetna” query below, it’s more clear to the user that the Doctors vertical is filtering down to doctors whose Primary Specialty = “Cardiology”:
We will have these frontend UI features enabled in our Healthcare Solution Template at Spring ‘21 GA.
Existing Accounts - Updating Your Config 
If you are going through through the process of migrating your current config to the latest best practices, please make sure you do the following:
- Always run a Version Comparison between your current production label and the staging label with your changes.
- Try to isolate feature improvements in Version Comparison. For example, if you are removing NLP Filters from your Provider names, you should isolate that improvement in Version Comparison, approve the changes, and then move to your next improvement and repeat the testing process.
- Take note of any regressions and try to determine any root causes. For example, you may have account-specific configuration, such as a lingering NLP Filter on a keywords field, that is impacting search quality. Make sure to use Version Comparison and Search Logs to identify why results are returning a certain way. If you would like to flag regressions that become themes or trends, you can follow up in the post for assistance.
- Make sure to let your client know that you are rolling out configuration changes to align with our algorithm updates and configuration best practices. Of course, our Product and Engineering teams have signed off on these best practices!
New Accounts - Applying a Solution Template 
We have updated our Healthcare Solution Template to contain the latest configuration best practices as outlined above. If you are setting up a new healthcare account, we recommend you always apply the Solution Template to your account to ensure that you are starting fresh with the best practices.
If you want to test out the template in a Sandbox environment, you can always create a playground account from your Hitchhikers Control Center, apply the Healthcare Solution template, and test out some queries.
As always, reach out in this post or in the Community with any questions!