We methodically worked on how we can empower our users — to save them time, to cut out the dull misery and monotony, to improve data quality and reuse and to conduct efficient research. All in a single platform. No need to use multiple tools and platform combinations.
Nobody should have to learn a markup language to update a paragraph, correct a dosage table or insert a new image.
The structure a regulator requires is a storage concern — the platform's problem, not the author's. So what you open is not a file. It is your label, rendered the way it actually reads: sections, headings, paragraphs, tables and images, in place, on the page. You change what you can see. Underneath, the structure the FDA and Health Canada require is written, maintained and checked for you while you work.
What that actually changes
- A regulatory professional edits a label in their first hour, not their sixth month
- Routine changes stop being a ticket to somebody else and start being a few minutes of your own afternoon
- The updated label is in your library the moment you review and approve the edits
- We take care of all the XML grunt work behind the scenes for you
In our worldview, speed of conversion matters … a lot.
We took these PDFs from DailyMed and Health Canada and ran them through our proprietary pipeline to see how long it will take to generate SPL/SPM XML. This is what happened:
DailyMed
KEYTRUDA QLEX
- 267 PDF pages, excluding metadata
- 111 tables
- 50+ figures
- Medication Guide
Pipeline execution (95%+ XML generated)5m 24s
DailyMed
REMICADE
- 61 PDF pages, excluding metadata
- 12 tables
- 4 figures
- Medication Guide
Pipeline execution (95%+ XML generated)1m 21s
Health Canada
PrDARZALEX® SC
- 137 PDF pages
- 59 tables
- 12 figures
- 1 patient medication information
Pipeline execution (95%+ XML generated)1m 32s
Our goal is to turnaround in 2 days or less, including time for our thorough QC processes.
Metadata without the misery
You are never asked to type something the system can already look up
Pilot UsOur rule: if an identifier already exists somewhere, we retrieve it rather than ask you to retype it.
Dozens of fields, identifiers scattered across FDA datasets, no way to check your work until you submit. On a large label that is hours of typing and a real risk of a transposed digit nobody catches.
Enter a SetID and the last version populates the form. Product identity, ingredients and establishments are filled from FDA data or your own saved records, not typed from memory. A manual edit always wins.
A live rendered preview runs alongside the form in DailyMed's own format, so you see the label as it is built rather than after you submit it.
We go to great lengths to ensure that using AI never leads to hallucinations on source content.
We use AI where it makes you faster. We keep it away from the artifact that gets filed. That single decision is the whole of our AI policy.
Break silos and free the content.
FDA does not publish one database. It publishes a dozen, none of which were designed to talk to each other, and the questions that actually matter in regulatory operations sit across several of them at the same time. DailyMed and many other siloed FDA data sources are connected behind the scenes, so a query resolves in minutes rather than an afternoon of browser tabs.
How it works
The model plans. You approve. The search runs on records, not guesses.
You ask in plain language. Before anything executes, the engine writes out the plan it intends to follow and shows it to you — so you can approve it, refine it, or throw it away. Then the search runs against the connected corpus, and every result resolves to a record you can open.
Your own content is never part of that corpus. Research runs against public regulatory data only. Your unpublished drafts, your in-progress submissions and your working files stay in your workspace and are never mixed into the research index — not for your queries, and certainly not for anyone else's.
Trust but validate.
A conversion is only as good as what checks it. So we did not just write a pipeline — we wrote the engines that judge its output, for all three formats we support.
SPL validation engine
We wrote our own engine against FDA's SPL business rules rather than relying on a single external opinion. We then triangulate our own results against other open-source, publicly available validators so that we can identify all possible issues we need to address.
Health Canada validation engine
There is no publicly available validator for the Standard Product Monograph. Everyone working in this market is effectively guessing until Health Canada responds. So we built one — all 79 rules, running against your content before anything is filed.
SPL FHIR R5 validation engine
We built our own version regardless. Better to triangulate than to just rely on one data point.
Our POV: you do not need FHIR today for US submissions, nobody can tell you when you will, and when the answer changes we will already have shipped it. Buying a labeling platform in 2026 should not require a bet on a standard that HL7 itself describes as still moving.
We serve the United States and Canada. That matters here, because almost every urgent FHIR message in this market is really an argument about Europe and Jordan.
Where the standard actually stands. FDA uses SPL today and has published no timeline for replacing it. The ePI implementation guide is a global core guide developed by the Gravitate Health project and HL7's Vulcan accelerator on FHIR R5. HL7 states plainly that anything at draft or trial-use status remains subject to change — including major refactoring — with no commitment to backward or forward compatibility until it reaches normative status. Regulators are moving at very different speeds. The EMA is still developing its own approach.
What we did about it anyway. We built an SPL-to-FHIR converter, scoped to FDA-facing SPL, and it is complete today. Because our pipeline resolves a label into structured semantic content before emitting anything, FHIR is an output step rather than a rebuild.
We plan to keep innovating to deliver more value over time.
Tell us what to build after you see a demo.
We can share what is on our roadmap already. If there is something your team needs that is not here, bring it to us. We would rather hear the problem from the person who actually has it than guess at it from the outside. Good ideas go on the roadmap, and we will tell you plainly where they sit and when you can expect them.