Demos
Reusing clinical annotations across projects means importing existing labeled datasets into a new project even when the label schemas differ. The usual blocker is label schema drift: the same clinical concept appears as “diagnosis,” “Diagnosis,” or “Primary_Diagnosis” across projects, so imports fail on naming alone. Generative AI Lab resolves this with no-code, import-time label mapping, letting teams reuse annotated data without rewriting schemas or hand-editing JSON. 
Import fails. Not because the data is wrong. Not because the annotations lack quality. But because: diagnosis ≠ Diagnosis
A healthcare organization has 5,000 annotated clinical notes from previous projects. The entity boundaries are accurate. The labels are semantically correct. One team’s work can bootstrap another team’s model.
Except the label naming conventions differ. One project used lowercase. Another used title case. A third used underscores and abbreviations. The clinical meaning is identical. The technical mismatch is absolute.
So someone spends days writing scripts to rename labels. Days to transform data that was already annotated, already validated, already sitting in the system. The friction is not in creating annotations. The friction is in reusing them.
This is the hidden cost of annotation schema drift.
Why annotated datasets lose value when schemas change
Healthcare teams understand that annotated clinical datasets are long-term assets. A health system invests years building diagnosis extraction data, de-identification masks, medication entity annotations, and adverse event labels across multiple projects. These datasets represent substantial organizational knowledge: annotator expertise, guideline development, quality validation.
Yet that knowledge becomes difficult to reuse the moment label schemas change. And schema evolution is inevitable. Teams evolve. Requirements shift. New vendors bring different conventions. A project that used “Diagnosis” in 2019 uses “Primary_Diagnosis” in 2023. Neither is wrong. Both create integration friction when teams try to combine data across projects.
Why label schemas drift as annotation programs mature
Label schema evolution is not a sign of poor planning. It is a natural consequence of how annotation programs mature.
A healthcare organization launches its first NER project. The schema is simple:
First project (2019):
- Problem
- Treatment
- Test
The project succeeds. The team learns. Guidelines improve. New use cases emerge. A second project starts, and the schema reflects accumulated learning:
Second project (2021):
- Diagnosis
- Medication
- Lab
Two years later, a third project accounts for clinical complexity that earlier schemas did not capture:
Third project (2023):
- Primary_Diagnosis
- Secondary_Diagnosis
- Medication_Name
- Laboratory_Result
This evolution happens because teams learn, external vendors participate in different projects, clinical requirements become more specific, and annotation guidelines improve. It is not a failure of schema design. It is normal organizational development.
The clinical knowledge encoded in all three datasets is sound. The annotations in each project are valid. The underlying entities are correctly identified. But the label names have drifted incrementally over time.
Why constant data movement makes annotation reuse essential
Five years ago, annotation projects were largely isolated. A team built a dataset, trained a model, deployed it, and moved on. Data rarely moved between projects.
Today, healthcare AI programs operate differently. Organizations maintain:
- Multiple annotation teams working in parallel on different initiatives
- Multiple models running simultaneously on overlapping patient populations
- External vendors submitting pre-annotated outputs that require integration
- Synthetic data pipelines generating candidates for human validation
- LLM-powered preannotation that accelerates manual annotation workflows
- Multi-generational models where earlier versions’ training data bootstraps newer versions
Data moves constantly. Annotations flow between projects, teams, vendors, and systems. Reusing annotated datasets is no longer convenient optimization. It is operational necessity.
When data moves this frequently, schema flexibility becomes a requirement. Teams cannot afford to spend days preprocessing JSON files to rename labels. They cannot maintain perfect schema consistency across every project and every external partner. Generative AI Lab gives them exactly that: import-time label mapping that tolerates the schema evolution mature healthcare AI programs produce.
How Generative AI Lab maps divergent labels at import
Generative AI Lab reconciles these schema differences at import while keeping governance over label definitions intact. Instead of hand-editing JSON files, teams work in a no-code review: Generative AI Lab identifies likely matches, presents them for review, and applies the approved mappings as data is imported.
Generative AI Lab maps a label such as “diagnosis” directly to “Diagnosis” through case-insensitive matching, and surfaces more complex variations such as “Medication_Name” and “Medication” as suggested mappings for human review. Project administrators retain control over the final mapping decisions, ensuring that schema normalization remains both auditable and predictable.
Once mappings are approved, annotations can be ingested using the project’s standardized schema without modifying the source data.
The key principle is human oversight. Generative AI Lab proposes, you approve, it executes – keeping the human-in-the-loop control healthcare requires and every mapping auditable.
Why reusable annotations are your most valuable clinical datasets
The most valuable clinical datasets are rarely the ones created for a single project. They are the datasets that continue generating value across multiple initiatives, teams, and generations of models.
Reusing those assets requires more than preserving the annotations themselves. It requires workflows that can accommodate the inevitable evolution of labeling standards over time. When schema drift happens (and it will), teams need mechanisms to integrate existing data without prohibitive preprocessing costs.
As healthcare AI programs mature, the ability to carry annotation investments forward may become just as important as creating them in the first place. Organizations that build this capability into their annotation infrastructure unlock the full value of years of accumulated clinical knowledge. Those that do not face the same friction repeatedly: spending days renaming labels that mean the same clinical thing, redoing work that was already done, and failing to leverage annotation assets that could accelerate new projects.
The future of healthcare AI is not building isolated datasets for isolated projects. It is building annotation workflows that make data portable, schemas flexible, and existing work reusable across the full lifecycle of clinical AI programs.
See label mapping in action: schedule a Generative AI Lab walkthrough or open the demo notebook. [Insert the link before publishing.]
Frequently Asked Questions
Does flexible label matching apply to all label types?
Yes. In Generative AI Lab, the matching layer works across NER labels, assertion labels, classification labels, and relation labels. Any label type that undergoes schema evolution can be mapped during upload.
What happens if a label in the uploaded file has no plausible match in the project schema?
If no suggestion meets the similarity threshold and the user does not define a custom mapping, the import can proceed with that label unmapped (if configured to allow unmapped labels) or rejected (if strict matching is required). The system provides clear feedback about which labels could not be mapped.
Are mappings permanent, or can they change between uploads?
Mappings are configurable per upload. Users can define different mappings for different imports of the same data source, though most teams maintain consistent mappings across repeated uploads from the same source.
Does this feature handle semantic differences, or only syntactic ones?
This phase focuses on syntactic matching: case differences, minor naming variations, underscore conventions. Complex semantic mapping (e.g., mapping “Primary_Condition” to “Diagnosis” based on clinical meaning) requires human judgment and is handled through manual mapping during the review step.
Does label mapping change my original annotation files?
No. Once mappings are approved, Generative AI Lab ingests annotations using the project’s standardized schema without modifying the source data.
What causes label schemas to drift between annotation projects?
Schema drift is normal as annotation programs mature: teams learn, guidelines improve, external vendors bring different conventions, and clinical requirements become more specific. The same concept ends up labeled “diagnosis,” “Diagnosis,” or “Primary_Diagnosis” across projects.
