On today’s OCL Squad Call, we uncovered some inconsistencies with how the name type for synonyms is handled in OCL. Specifically, synonyms (like “CHF” for “Congestive Heart Failure”) have a null
name type in OCL’s API, but the OCL UI requires a name type, where None
(not null
) is one of the name types and, if chosen, None
(not null
) is stored.
OpenMRS’ user interface doesn’t use name types; rather, the following are properties of a concept in the edit concept form:
- A fully-specified name
- An optional list of synonyms
- An optional list of search terms (i.e., “index terms”) to use for indexing, but not for display (e.g., common misspelling)
- An optional short name (for use in flowsheet or spreadsheet, where names need to be abbreviated)
When these values are stored in the OpenMRS concept_name table
, the concept_name_type
is set to one of these values:
FULLY_SPECIFIED
SHORT
INDEX_TERM
or left empty (null
) for synonyms.
Within OCL, there are corresponding NameTypes:
Fully-Specified
Short
Index-Term
None
When dictionaries (like CIEL, PIH, etc.) are imported, we are setting the name types for synonyms to “” (a blank string) per this line:
concept_name.concept_name_type if concept_name.concept_name_type else ''
In brief, for synonyms in OCL, we are currently:
- Importing as
name_type: ''
- Storing
name_type: null
- When adding/editing in UI, using
name_type: None
This is going to lead to a future where synonyms have a name_type
of null
or None
depending on how they got into OCL.
FWIW, showing “None” in the UI like this is confusing (i.e., not a good UX):
Trying to decide on a way forward:
Choice | Steps |
---|---|
Embrace ‘null’ |
|
Embrace None |
|
Introduce 'Synonym` |
|