Two clinicians outline the same finding almost identically. One records it as “present”; the other records “indeterminate” because the acquisition quality is poor. Geometry agreement looks excellent, but the clinical label carries a different meaning downstream.
Medical annotation must separate what is visible, what is inferred, and what cannot be assessed. Medical resources in Unitlab combine structured ontology controls with a synchronized multi-view workspace inside a typeless project, so specialists can review connected planes and supporting context without splitting one study across unrelated tools.
Clinical AI data needs more than accurate geometry. A region may be marked correctly while its finding, severity, visibility, or uncertainty is represented poorly. The annotation system must connect location with clinical meaning, preserve reviewer accountability, and make schema changes visible across the life of the dataset.
When a medical resource opens, Unitlab selects the native medical workbench and presents the study in synchronized axial, sagittal, coronal, and 3D views. A contextual document can sit beside the imaging workspace in a grouped layout. That creates a practical pattern in which a spatial label identifies where, structured properties capture what the observation means, and the specialist checks the decision across views without losing case context.
The workspace provides the operational surface; a clinical program still defines its acceptance criteria for representative studies, rendering fidelity, interaction performance, privacy, access, expert review, and exported label semantics.
The medical workspace
The medical workspace combines multi-planar and 3D viewing with the same operational foundation used elsewhere in Unitlab: spatial drawing and editing, object and class inspection, properties, relations, comments, tags, item navigation, and workflow actions. DICOM slices are grouped by series into one user-facing volume; DICOM, NIfTI, and NRRD can enter through the mixed-data ingestion path.
One medical ontology included a clinical-finding property with options such as Normal, Degenerative changes, Compression fracture, Scoliosis, Hardware present, and Lesion. The example demonstrates structured clinical classification; it does not establish a universal schema. A real implementation should be designed and approved by the appropriate domain experts for its intended use.
The shared workbench is valuable operationally. Teams can use boxes, polygons, masks, lines, keypoints, or other available geometry where appropriate, then attach properties to the object or item. Comments preserve case-specific context, while review and completion actions follow the project's workflow.
Medical viewing and temporal controls
View Settings provides Hounsfield-unit presets plus saved custom window/level presets, VOI LUT and histogram controls, window-width and level ranges, 3D threshold and opacity, and projection modes including single slice, MIP, MinIP, and average with slab thickness. Tab + ←/→ adjusts width and Tab + ↑/↓ adjusts level. These settings change the inspection view, not the source study.
The timeline coordinates geometry and frame-aware meaning across slices or frames. Dynamic class properties let one finding keep its identity while a value changes through the sequence; Dynamic Item Properties record study- or frame-level states such as procedure phase or overall quality. Rows, ranges, keyframes, playhead navigation, and auto-zoom connect the selected timeline state to the active view.
A specialist's path through one grouped study
Consider a grouped case containing a DICOM series and a referring document. The saved Custom Layout opens both resources together. The imaging panel is active for drawing and medical navigation; the document panel remains passive context until the specialist activates it. Switching panels changes the toolbar and inspector to the selected resource without changing the grouped work item's workflow identity.
The specialist starts in the axial view and applies the appropriate window/level preset. Sagittal and coronal views remain synchronized to the same location, while the 3D view provides orientation. If a projection makes the observation easier to confirm, the user switches from single slice to MIP, MinIP, or average projection and adjusts slab thickness. These are viewing decisions; the underlying source remains unchanged.
After locating the observation, the specialist selects the ontology class and draws the geometry required by the task. The object appears in the inspector and on its timeline row. Class Properties capture finding type, visibility, severity, certainty, or another approved object-specific field. An Item Property records study-wide context such as acquisition quality; it is answered once rather than copied onto every finding.
If a property changes across slices or frames, it is marked Dynamic. The specialist moves the playhead to the first frame where the new state applies and enters the value. Unitlab creates a temporal range beneath the object track, or an independent row when the changing value is a Dynamic Item Property. Auto-zoom and row selection keep the active evidence and temporal state aligned.
The specialist then reviews the observation across all synchronized views, adds a comment when case-specific reasoning must survive the handoff, and uses the workflow action to send the item to specialist review. The reviewer can correct geometry separately from meaning, reject the item with context, or accept it into the approved path. One case therefore preserves source context, spatial evidence, structured clinical meaning, temporal state, and review history as a single operation.
Separate geometry, finding, and confidence
A robust medical ontology avoids encoding every variable in one class name. Consider a finding that has a location, category, severity, certainty, and visibility. Creating a class for every combination becomes unmanageable.
A cleaner structure is:
- Geometry: the spatial extent of the observation.
- Primary class: the concept being localized.
- Object properties: severity, appearance, certainty, or subtype.
- Item properties: exam-level or image-level context.
- Relations: clinically meaningful connections between objects, if required.
| Question | Suggested schema layer | Why |
|---|---|---|
| Where is the observation? | Box, polygon, mask, keypoint, or line | Separates position from meaning |
| What type of observation is it? | Class | Stable primary label |
| How severe or certain is it? | Object property | Avoids class explosion |
| What applies to the whole image or study item? | Item property | Keeps global context out of geometry |
| How are two findings connected? | Relation | Preserves explicit structure |
This model also makes review more diagnostic. A reviewer can distinguish a boundary correction from a semantic-class correction or a missing property.
Choose geometry from the clinical objective
Boxes are efficient when approximate localization is sufficient. Polygons and masks support more precise contour or area representation. Lines may be useful for a path or boundary; keypoints for landmarks; skeleton-like structures for predefined connected landmarks where the use case supports them.
Precision should be justified by downstream value. Pixel-accurate segmentation is expensive and can create misleading confidence if the source itself has ambiguous boundaries. When experts cannot consistently identify an edge, a soft scientific uncertainty should not be disguised as a sharp annotation policy.
Guidelines should cover partial visibility, artifacts, low-quality acquisition, postoperative changes, multiple findings in the same region, and the boundary between “normal variation” and the target condition. Provide both positive and near-negative examples.
Build the ontology with clinical governance
Unitlab ontologies support class descriptions, colors, hotkeys, attributes, single- and multi-choice properties, text properties, and relations. The ontology area includes draft and live states, version history, JSON representation and export, entity search, and visual summaries.
Use the draft state for multidisciplinary review. A domain specialist should assess clinical meaning, an ML lead should assess downstream representation, and an operations lead should test whether annotators can apply the rules at speed without guessing. Legal, privacy, or quality stakeholders may require additional approval depending on the context.
Avoid free text where structured values can capture the same information. Free text is valuable for exceptions and expert commentary but difficult to normalize. If a concept is important enough to train or evaluate on, it usually deserves a controlled option and an explicit unknown or not-assessable path.
Human review is part of the label definition
Review should be designed according to risk and expertise. A general annotation reviewer may verify geometry and completeness, while a qualified domain reviewer resolves clinical interpretation. Unitlab's workflow builder can place Annotate and Review stages in sequence, assign a person or allow eligible members, and route rejected work back through correction.
For a high-stakes pilot, consider independent annotation followed by adjudication on a shared benchmark. Measure agreement separately for presence, class, boundary, severity, and certainty. A single overall score can hide a clinically important disagreement.
Use annotation comments for case-specific reasoning. Use project issues when the matter needs an owner and status—for example, a corrupted asset, unclear acquisition context, or schema question affecting multiple items. Keep the approved instructions attached to the project through rich text, external links, or uploaded files.
Roles and permissions create operational boundaries
The live Unitlab organization area exposes configurable roles and permissions rather than only a fixed list of user types. A role can be defined around project, asset, dataset, release, ontology, workflow, AI model, member, and role-management capabilities.
For a medical program, least privilege is the starting point. Annotators should access only the projects and data needed for assigned work. Review authority should reflect expertise. Ontology publishing, role changes, data-source configuration, and release creation should be limited to accountable owners.
Permission configuration alone is not a complete compliance program. Teams must also validate their contractual, privacy, security, retention, audit, and deployment requirements. The platform controls support an operating model; organizational governance defines the model.
A worked schema example
Suppose a team is evaluating a 2D imaging task that localizes a suspected finding and records structured assessment. The ontology might contain one spatial class for the finding, an object property for assessment category, an object property for visibility, and an item property for overall image quality. A free-text comment is reserved for unusual interpretation—not used as a substitute for the controlled properties.
The domain owner defines whether the geometry represents the visible extent, an estimated complete extent, or a standardized measurement region. Clear and borderline examples are reviewed independently. When reviewers disagree, they record whether the issue is presence, boundary, category, visibility, or source quality.
This separation prevents a single class name from encoding every combination. It also lets downstream teams choose which signal to use and lets quality teams find where disagreement concentrates.
Build a validation matrix
Validate the platform and process across the actual dimensions that matter:
| Dimension | Pilot question | Evidence to collect |
|---|---|---|
| Format | Does representative media load and render consistently? | Success, failure, processing time, metadata |
| Geometry | Can experts express the required region or landmark? | Accepted examples and correction time |
| Clinical structure | Are required categories and uncertainty states available? | Ontology review and calibration agreement |
| Workflow | Can annotation, specialist review, rejection, and correction operate? | Stage transitions and audit notes |
| Access | Do roles expose only the required cases and controls? | Allowed/denied action test |
| Release | Can the approved data and labels be traced and delivered? | Release manifest and consumer validation |
Do not approve the pilot on screenshots alone. Ask a different team member to reproduce the path from approved source to released label.
Make uncertainty explicit
Medical data often contains legitimate ambiguity. A mature annotation system does not force certainty where the source does not support it. Use an approved not-assessable or uncertain state, define when it is appropriate, and review its frequency. Too few uncertain labels may indicate guessing; too many may indicate unclear criteria or unsuitable source data.
When a schema changes, Unitlab can warn that existing annotations refer to deleted ontology items and offer a restore decision. Treat that warning as a migration checkpoint. Assess affected labels, document the new meaning, and create a new release rather than silently rewriting history.
A temporal medical-labeling example
Suppose a sequence follows one finding across slices while visibility changes. The finding remains one annotation object. A Dynamic class property records Visibility = Clear, then Partial, then Not assessable at the frames where the evidence changes. Its child row on the timeline makes those transition points reviewable without splitting one finding into several identities.
At the same time, a Dynamic Item Property can record Procedure phase for the complete sequence. That scene-level state appears on its own timeline row rather than being duplicated on every finding. The specialist can select a property range, jump to the relevant slice, compare synchronized views, and use window/level or MIP controls to inspect the evidence. Geometry, finding state, and sequence context remain separate but temporally aligned.
The release should preserve those distinctions and the ontology version that defined them.
Rehearse one study from grouped evidence to specialist review
Suppose a study contains an axial series, a coronal reconstruction, a prior image, and a short clinical note. The task is to localize a finding, record severity and visibility, and classify the study-level outcome. The first design decision is not which drawing tool to select; it is how those resources should appear together so the specialist can make one evidence-based decision.
Auto-Grouping can bind resources through stable metadata, and a Custom Layout can place the active diagnostic series beside supporting views. An active panel is labelable; a passive panel supplies context. That distinction prevents a reference image from silently becoming another annotation surface. Synchronized navigation can keep compatible views aligned, while window/level presets and image adjustments help inspect the evidence without changing the source data itself.
Create the finding with the geometry required by the model: a point for a landmark, a box for coarse localization, a polygon or mask for extent, or an appropriate 3D form when the task needs volumetric meaning. Geometry says where the evidence is. The class says what it is. A Class Property records details such as severity, confidence category, or morphology on that specific finding. Item Properties hold study-level conclusions, acquisition quality, or protocol information.
If a finding changes across frames or slices, a Dynamic Class Property can preserve one object identity while the state changes on the timeline. A Dynamic Item Property is appropriate for a sequence-level phase or quality state that changes independently of one object. Required does not mean “force certainty”: include cannot_assess, not_visible, or another controlled option when the evidence can be insufficient.
The specialist should scan the grouped study before drawing, identify the best evidence plane, place the annotation, and then challenge it in the supporting view. If the representation appears inconsistent across planes, pause rather than resolving the conflict through guesswork. A comment can explain a source-specific ambiguity; a project issue should capture a repeated policy question that needs an owner and resolution.
Review follows the same evidence chain. The reviewer checks resource grouping, view selection, geometry, class, properties, and study-level output. For temporal or volumetric work, they inspect keyframes or representative slices and the transitions between them. The goal is not merely inter-reader agreement; it is a reproducible label definition that makes uncertainty explicit and preserves the context required to interpret it.
Before production, run a validation matrix that includes obvious positives, hard negatives, post-treatment change, artifacts, missing priors, and low-quality acquisitions. Classify disagreement by source insufficiency, localization, class, severity, temporal boundary, or instruction ambiguity. This avoids treating every difference as an annotator mistake and shows when curation, ontology, or review policy should change.
The final handoff should record the grouped inputs, ontology version, workflow path, reviewer decision, and release version. That record lets a downstream team distinguish a model failure from a changed label definition or a missing modality. In regulated or high-risk work, this provenance is part of the product, not administrative decoration.
Before acceptance, verify that the grouped study contains the intended patient or case context, each active panel has the correct annotation role, and passive reference material was not accidentally labeled. Reset temporary display changes when they could confuse the next reviewer, and confirm that window/level or image adjustments supported inspection without altering the underlying source.
The reviewer should also challenge absence labels. “No finding” is a positive decision about a sufficiently assessable study, not a synonym for missing evidence. If the required view is absent or quality is inadequate, use the controlled quality or uncertainty path so negative training data remains trustworthy.
A specialist calibration and safety pilot
Choose studies that reflect the intended use: clear positives, clear negatives, subtle findings, artifacts, post-treatment change, missing priors, low-quality acquisition, conflicting views, and multiple findings. Group the exact resources a specialist will use and record which modalities or views are required, optional, or unavailable.
Configure the Custom Layout with active and passive panels, synchronized navigation where appropriate, and the medical viewing controls needed for the task. Verify orientation, series identity, window/level behavior, projections, and any 3D context before annotation begins. Ask a specialist outside the setup team to navigate the study without coaching.
Have at least two qualified readers label a calibration cohort independently. Compare finding presence, geometry, class, severity, properties, study-level Item Properties, Dynamic state, and uncertainty. Do not collapse every difference into one agreement score. Separate localization, interpretation, assessability, temporal boundary, and schema disagreement.
Review the disagreements with the same grouped evidence. If the source genuinely does not support a decision, add or refine a controlled uncertainty state. If the geometry is inconsistent across views, clarify which plane or representation is authoritative. If severity depends on context not shown in the layout, change the grouping or scope rather than asking readers to infer it.
Define the review path by risk. New classes, subtle findings, low-quality studies, and high-impact labels receive full specialist review. Mature, well-calibrated tasks may use targeted sampling, but absence labels and uncertain cases should remain visible. Roles should let specialists review the necessary data without granting unrelated administration.
Finally, export an acceptance cohort and confirm spatial coordinates, frame or slice references, properties, study identifiers, and ontology version. Create a release with inclusion criteria, modality completeness, reader policy, uncertainty handling, and known limitations. The pilot succeeds when the annotation can be interpreted by another specialist and reproduced by a downstream team—not merely when every study has a status.
Try the workflow in Unitlab
- Open the Medical Annotation demo and inspect the same structure in axial, sagittal, coronal, and 3D views; confirm synchronization and rendering at the detail level the task requires.
- Review the ontology before labeling: finding, location, visibility, severity, and uncertainty should be separate only when each is observable and useful.
- Annotate one clear case and one ambiguous case. Use explicit uncertainty rather than forcing a confident value.
- Route both to a qualified reviewer and preserve the reason for any correction.
- Validate export, metadata, access roles, and release lineage with the downstream clinical or research owner.
Measure reviewer agreement by finding and uncertainty state, missing required context, rendering failures, correction severity, and release exclusions. Do not generalize from a single demonstration image.
The decision to make
Use de-identified representative cases and a qualified reviewer. Evaluate the Unitlab medical workflow against your real viewing, ontology, security, and export requirements before production.
