Tag
“Tags that might be used to categorize the finding among other findings.”1 Tags are an optional list of free-text strings on a finding model. The authoring guidance describes them as “clinical categories (anatomy, modality, etiology) for organization and retrieval.”2
Tags are untyped and unvalidated. A real definition in the corpus carries ["ultrasound", "CT", "US", "XR", "urological", "obstructive", "diagnosis"] on one finding, mixing modality abbreviations, two spellings of the same modality, a subspecialty, an etiology, and an entity type in one list. That looseness is the reason the metadata rewrite exists.
Synonyms and near-synonyms
- Structured metadata field is the typed successor. The documented rewrite adds
body_regions,subspecialties,etiologies,entity_type,applicable_modalities,expected_time_course,age_profile, andsex_specificityas optional fields with closed value sets.3 - Facet was the earlier name for that same idea under an eight-facet scheme; it is superseded by the field set above.
- Index code is not a tag. It points into an external ontology; a tag does not.
- Category in a finding taxonomy is a separate per-row anatomic grouping, not this field.
Identifier form
None. Tags are bare strings with no registry.
Where it is used
Finding model format and Enrichment pipeline.
Conflicts
Tags and the new typed fields overlap: a tag reading CT and an applicable_modalities entry of CT say the same thing in two places. The rewrite states that structured metadata should be canonical model state rather than sidecar output, but it does not say what becomes of the existing tag lists, and nothing has landed on main.3