SPL / Labeling · Labeling / Medical-Writing Lead
CuRE Cachet
SPL / Prescribing-Information authoring and label-version lifecycle.
What it does
SPL / Prescribing-Information authoring and label-version lifecycle. AI-assisted label authoring grounded in the structured product record — drafts cite the registration and submission facts they came from.
Key capabilities
- SPL / PI / product-label authoring
- Label content management
- Label-version lifecycle
- Label ↔ registration linkage
- Company Core Data Sheet (CCDS) → core-to-local
- AI label-safety reconciliation vs platform safety
- HL7 SPL XML generation
- RLD surveillance feed
What sets it apart
- AI-assisted label authoring grounded in the structured product record — drafts cite the registration and submission facts they came from.
- A Company Core Data Sheet drives country/local label derivation, and label safety content reconciles against the platform safety source-of-truth (Canary/RWD) — the connected-safety edge standalone labeling vendors lack.
- Multilingual labels, SPL/eDRLS validation, ePI/FHIR, content reuse, IMP labels, RLD surveillance, orchestration, and artwork handoff are part of the labeling surface.
- Label ↔ registration linkage with Consulate keeps every market's label and approval status in lockstep.
- Finished labels publish through Consign sequences — one publishing pipeline, no export-and-rekey.
Diff two SPL label versions, section by section
A prescribing-information label is a tree of LOINC-coded SPL sections, and every version is a full copy of that tree. Pick a prior and a new version of a synthetic drug label and watch Cachet compute the structured diff on read — which sections were added, removed, or changed, down to the field and the side-by-side body text — the same way a labeling lead reviews a safety labeling change.
A synthetic prescribing-information label for a fictional oncology drug, VELT-042, authored as LOINC-coded SPL sections. Each version is a full copy of the section tree.
Safety labeling change: add Boxed Warning; PLLR §8 conversion; AE update.
The diff is computed on read from the two versions' section rows — Cachet stores no materialized diff.
Structured section diff · SPL display order
19 leaf changesEach section is keyed by its LOINC document-section code — not its row id — so the same section diffs correctly even though every version copy remints the row ids. Click a changed section to see the prior and new body text side by side. Every classification is computed in your browser; nothing calls a backend.
Why this is more than a toy
The diff is a faithful, dependency-free port of Cachet's real compute-on-read structured diff (apps/cachet/…/labels/diff.ts): the same canonicalization of each version's section rows into a stable object keyed by LOINC code (with the #n ordinal suffix for repeated codes and id-independent parent linkage), then the identical flatten → union-of-paths → classify core it shares with Cascade's amendment diff. Keying on the LOINC code rather than the row id is what makes it correct — Cachet remints section row ids on every version copy, so an id-based diff would read as 100% churn. Cachet stores no materialized diff; it is recomputed from the persisted versions at any later audit, so the same diff reproduces byte-for-byte (the product asserts this in its diff.test.ts). Per the platform's analytics-placement boundary (ADR-PLT-044) this is event-write-bound operational math that lives in-app, not in Calculate. Here it runs entirely client-side on synthetic label sections — no backend, no real data.
See CuRE Cachet in action
Every research ecosystem is unique. Let's discuss how CuRE can be configured for your needs.