I think we settled on this:

Definitions

synonym -- an alternative name for a concept, including abbreviations or valid alternate spellings, or word substitutions. For example: COMPLETE BLOOD COUNT could have the synonyms CBC and WHOLE BLOOD COUNT

search phrase -- any phrase that may be useful when searching for a concept, but is not a valid (or useful) representation for the concept. These could be used for common misspellings, bar code values, and any phrase that might be helpful in aiding the search process but does not represent a valid name (or alternate name) for the concept. For example: TETRACYCLINE could have the search phrases TETROCICLINE (if that is often typed by users) and SUMYCIN (to allow look up by brand name without displaying brand name on reports).

Overview

The goal of distinguishing these two forms of alternate names would be to support the use of synonyms on reports -- i.e., if a doctor orders CBC, then she could see CBC on the list of ordered tests, even thought the primary name is COMPLETE BLOOD COUNT. Search phrases, on the other hand, would be immediately converted to the primary name, serving only to aid in the concept search process.

There are two phases to supporting this enhancement: 1) Update concept_synonym and the UI to support differentiating synonyms and search phrases 2) Update obs and order tables, the API, and the UI to persist synonyms used to find concepts. Essentially, anywhere we persist a concept linkage would need an additional varchar attribute to hold the synonym text used to create the linkage.

Distinguishing synonyms and search phrases

This could be accomplished by adding concept_synonym.search_phrase as a boolean with default false.

The concept edit UI would present synonyms as it does now, storing all these as rows in the concept_synonym table with concept_synonym.search_phrase = false. Then we'd add a second list below Synonyms that would be labeled Search phrases. All entries in the Search phrases list would be added to concept_synonym with concept_synonym.search_phrase = true.

Persisting synonyms

We would need to add a concept_synonym attribute to obs and order tables and then adjust the API and UI to use these attributes to (1) persist the text used to select a concept and (2) use this text, when non-null, instead of the concept's primary name on reports and for display.

After some discussion, we realize that we need to store a unique ID for each synonym, necessitating concept_synonym.concept_synonym_id.

It looks like we're going to fold synonyms into concept_name. Paul's going to mock up the model on the wiki.