/
Build and maintain a tag library in Dermi Atlas, with color-coded categories, tag assignment across patients, entries, and images, inheritance, and CSV import and export.
As a clinical image library grows, retrieving the right records depends on a consistent vocabulary rather than on memory. Tags supply that vocabulary: a set of labels the practice defines for itself, grouped into color-coded categories, applied to patients, clinical entries, and individual images, and then used to filter any of those views.
Dermi Atlas keeps the tag library on a dedicated Tag Management page and offers it wherever a record can be labeled. Tags applied to an image also surface on the parent entry and patient record, so a patient record reflects every classification recorded beneath it without the same label being applied three times. This article covers building the library, assigning tags across the record hierarchy, filtering by tags, and moving a library between deployments with CSV.
The Tag Management page is opened from the primary navigation sidebar, or from the "Tag Management" quick action card on the Summary page. It lists every tag category as a card, with the tags in that category rendered as pills inside it. A counter above the list reports how many categories exist, a single header control opens or closes every card at once (labeled Expand All while any card is collapsed, and Collapse All otherwise), and each card can also be collapsed on its own.
A search field at the top of the page filters the list. The term is matched against category names and tag names: a category whose name matches keeps all of its tags visible, while a category whose name does not match is shown with only the tags that match. Input is converted to lowercase and limited to 32 characters.
Every edit made on this page, including creating, renaming, recoloring, and deleting categories and tags, is held as a pending change. A persistent header bar reports the number of pending changes, broken down into categories and tags, and carries the Save Changes and Discard controls. Nothing is written until Save Changes is used, and Discard returns the page to the last saved state. Navigating away while pending changes exist raises a warning first.
A category groups related tags under a shared name and color. A practice might keep categories such as Body Region, Condition, or Treatment Stage, each holding the tags that belong to that classification. The category color is applied to every tag inside it, so the category a tag belongs to is legible at a glance on a patient card, an image card, or a filter bar.
Add Category creates a card named "New Category" and assigns it the next color in the palette. Repeated use appends a sequential suffix, such as "New Category - 1", so two new categories never collide before they are renamed. The name and the color are then edited directly on the card.
The category name is edited in place in the card title. The field accepts up to 20 characters and commits when it loses focus or when Enter is pressed. Category names must be unique; an empty or duplicate name is declined with a notification and the previous name is restored.
The Category Color control opens a palette of eight colors: blue, amber, fuchsia, emerald, violet, orange, cyan, and rose. Selecting one recolors the category and every tag pill inside it immediately, as a pending change.
Illustrative demo with synthetic data. Learn more
Each card carries an Auto-suggest from Category toggle. While it is enabled, the tags in that category are offered in the tag library whenever a record is labeled. While it is disabled, those tags are withheld from that library, and the category and its tags remain intact on the Tag Management page along with every assignment already recorded. This retires a classification from daily use without deleting anything.
A More Options control on each card holds two bulk actions:
Both actions are staged rather than applied immediately for categories and tags that already exist: a marked tag is restored from its own undo control, and a marked category from the undo control on its card, at any point before Save Changes is used. Categories and tags created in the current editing session are removed outright instead, since nothing has been saved yet.
A tag is a single label belonging to exactly one category. Tag names are stored in lowercase, accept up to 30 characters, and must be unique within their category. Each tag carries a usage count summarizing how many patients, clinical entries, and images it is directly assigned to; inherited appearances are not counted. The count is displayed beside the name and governs whether the tag can be deleted.
Tags are created in two places:
Illustrative demo with synthetic data. Learn more
A tag name is edited in place on its pill. The field lowercases input as it is typed and commits on blur or when Enter is pressed. A name that duplicates another tag in the same category is declined with a notification and the previous name is restored. Renaming does not disturb assignments: every record carrying the tag displays the new name once the change is saved.
Illustrative demo with synthetic data. Learn more
The trailing control on each pill marks a tag for deletion. A tag can be removed only while its usage count is zero; for a tag that is still assigned, the control is dimmed, and using it returns a notification explaining that the tag is in use. A tag marked for deletion is restored from the same control, which becomes an undo button while the change is pending.
While the page holds pending changes, every affected card and pill carries a colored status marker:
The blue and red markers sit beside an undo control that reverts that single change, while a green marker carries a delete control that removes the newly created item, so an editing session is reviewed item by item before Save Changes commits it.
Tags are assigned at three levels: the patient record, the clinical entry, and the individual image. Every level uses the same drawer, opened from the Assign Tags control beside the record's tag section or from the tag control on an image.
The drawer opens on its Library tab, which lists the available tags grouped by category, each as a selectable button in its category color. A search field narrows the list, matching against both tag names and category names, so searching a category name brings up everything it holds. Selecting a tag assigns it, and selecting it again removes it. A category whose Auto-suggest toggle is off contributes no tags to this list.
The Create tab defines a new tag without leaving the record, as described above. Assigned tags appear beneath the record's tag counter as color-coded pills, each with its own remove control.
On the patient details page, tag changes join the rest of the form as pending edits. A removed tag stays visible as a struck-through pill with an undo control, and the Save control in the page header commits the tag set together with the rest of the record.
Illustrative demo with synthetic data. Learn more
A clinical entry carries its tags in the Tags & Notes section, alongside its inherited tags and the assigned-tag count. The entry has no separate save step for tags: closing the drawer commits the assignment.
Illustrative demo with synthetic data. Learn more
Images are tagged from the Image Pool, using the tag control on an image card or list row, or from the Image Properties drawer. The tag chips on the card update as tags are selected and cleared in the drawer, and the assignments are written once the drawer closes.
Illustrative demo with synthetic data. Learn more
Tags applied lower in the record hierarchy surface automatically at the levels above:
Inherited tags are presented in a panel of their own, separate from the assigned tags and labeled with their origin: "Auto-inherited from images in Workspace" on an entry, and "Auto-inherited from the patient's entries and images" on a patient record. They are read-only where they are inherited and are changed at the level where they were originally assigned.
Inheritance keeps a patient record representative of everything documented beneath it without the same label being applied at each level, and it is what allows a tag filter on the Patient Database to return a patient whose only match is on a single image.
Tags feed the filtering tools in the Image Pool and the Patient Database.
In the Image Pool, a collapsible "Filter by tags:" section lists every tag currently assigned to an image in the pool, each with its category color and the number of images carrying it. Selecting one or more tags narrows the pool to the images matching any of them, a badge reports how many filters are active, and Clear Filters releases them all at once. See Uploading and Organizing Images for the rest of the Image Pool workflow.
In the Patient Database, the tag filter covers assigned and inherited tags alike, and the text search matches tag names as well as patient identifiers. See Patient Search and Filtering for the full filter set and how the filters combine.
Both bulk operations sit in the More Options menu of the Tag Management header bar.
Export Tags writes the whole library to a CSV file. Category names form the header row, and the tags of each category are listed alphabetically beneath their name. The file is named user-tags-YYYY-MM-DD.csv and is downloaded to the local device. The action becomes available once at least one category exists.
Illustrative demo with synthetic data. Learn more
Import Tags opens a file picker for a CSV file in that same shape: category names in the header row, tag names in the rows beneath. Files up to 5 MB are accepted. During the import:
Imported categories and tags arrive as pending changes carrying the usual status markers, so the whole import is reviewed, adjusted, or discarded before it is saved.
Illustrative demo with synthetic data. Learn more
Together, the two actions cover a practice that maintains one standard taxonomy across several deployments, or that wants to seed a new installation with an established library rather than rebuilding it by hand.
A tag library is a classification layer each practice defines for itself. Categories carry the axes that matter to the practice, whether anatomical region, condition, treatment phase, or follow-up priority, and the tags inside them carry the specific values. Because the same library is offered at the patient, entry, and image levels, clinicians can label a record at whatever level the observation belongs to and still retrieve it from any of the three.
Inheritance removes the duplication that layered labeling usually creates: an image tagged during a visit reaches its entry and its patient record on its own, so a patient record stays representative of everything documented beneath it. Usage counts and the zero-usage rule protect that structure over time, since a tag in active use cannot be deleted out from under the records that reference it, and every pending edit to an existing tag or category is reversible until it is saved. CSV import and export extend the same library beyond a single deployment.
Every feature described here is available in Dermi Atlas Professional, the on-premises deployment designed for clinical use. The Dermi Atlas Cloud Demo provides access to core workflows for evaluation, though some capabilities may be restricted.
Your feedback helps us improve our documentation
Contact our support team for personalized help
All demonstrations, screenshots, and media on this page use synthetic data only. No real patient information is shown.
The following are synthetic and do not correspond to real patients:
Media is provided solely to illustrate platform functionality and workflows.