Here's a thing that surprises people new to life-science data: most of the answers you need are already public. Free, even. The catch is that they're trapped in a format nobody can query.
A drug label lives as SPL XML. A device clearance lives as a 510(k) PDF. A patent grant is a different XML again. A trial sits in a registry with its own schema. A compound has one identifier here and a completely different one there. The information is right there — and totally unusable until someone does the unglamorous work of transforming it.
That transformation layer is the part of the data stack life sciences keeps forgetting to build. And it's the part that decides whether your AI is genuinely useful or just confidently wrong.
The scale of "free but unusable"
The public corpus is enormous. PubMed holds more than 40 million citations. [1] ClinicalTrials.gov has over 590,000 registered studies. [2] openFDA exposes over 259,000 structured drug-label records and more than 20 million adverse-event reports — drawn from sources that originate as PDFs and SPL XML. [3] ChEMBL catalogs nearly 2.9 million compounds and grows fast. [4] The USPTO has granted more than 12 million patents, adding ~327,000 a year. [5]
Each of these is a different format, a different identifier scheme, a different update cadence. The FAIR data principles — the canonical authority on reusable scientific data — note that data "usually need to be integrated with other data" and interoperate across workflows, which is precisely what these sources resist. [6] Free data is not the same as usable data.
Why transformation is harder than it looks
"Just parse the PDFs" is the most underestimated sentence in the building. The work isn't extraction — it's reconciliation. Once you've pulled fields out of a 510(k) and an SPL label and a patent, you still have to decide that the device, the drug, and the claim refer to the same real-world entity, across sources that never agreed on a name or an ID. That's entity resolution, and it's a global, quadratic problem rather than a per-document parse. (We've written about why that breaks naive approaches.)
The time cost is real and measurable. Mapping a single dataset to a standardized common data model took a median of 358 days across the EHDEN network, with only 52% of partners finishing on time — and vocabulary mapping was the most time-intensive step. [7] The data-integration tooling market reflects the demand: it's forecast to grow from $17.6B in 2025 to $33.2B by 2030. [8]
Why your AI dies without this layer
This is the part that's easy to skip and expensive to skip. Teams rush to bolt an LLM or a RAG system onto their data, and it hallucinates, contradicts itself, or cites the wrong drug — because the underlying data was never transformed and resolved. Gartner predicts organizations will abandon 60% of AI projects through 2026 for lack of AI-ready data, with 63% of data leaders lacking or unsure of adequate data-management practices. [9] The model isn't the problem. The unbuilt transformation layer is.
Garbage in, confident garbage out. A retrieval system pointed at unresolved data will happily retrieve the wrong entity and phrase it beautifully.
The highest-leverage thing you're not building
The transformation layer is unglamorous, which is exactly why it's underbuilt and high-leverage. It never makes the conference slide. It doesn't demo well. But it's the difference between a data strategy that compounds and one that produces a new brittle scraper every quarter. Build it once — ingestion, parsing, normalization, entity resolution, refresh — and every downstream analysis, dashboard, and AI feature inherits clean inputs. Skip it, and you pay the tax forever.
What's the public dataset your team most wishes it could actually query — and what's stopping you today?