EMA opens PMS product data through a public API beta
The June release expands access to structured medicinal-product data while marketing authorisation holders face staged manufacturer and pack-data enrichment deadlines.
Editorial figure by RegQuality Review. Source context: European Medicines Agency.
An access milestone, not a finished data programme
The public API beta changes how firms, researchers, and software providers can access a portion of EMA's structured product master data. It does not turn PMS into a complete public regulatory record, and EMA explicitly describes a beta period through early 2027. Consumers should expect schema, use-case, quality, and operational learning during that period.
For marketing authorisation holders, the more immediate challenge remains source-data quality and enrichment. EMA asks organizations to verify how XEVMPD or SIAMED data displays in PMS, resolve discrepancies, and gather structured manufacturer and pack information for non-centrally authorised products.
The RIM boundary is being redrawn
A mature RIM programme now needs to state which system owns each regulatory data element, who may change it, how authority data is reconciled, and where a discrepancy becomes a controlled issue. Adding an API connection without those decisions can accelerate inconsistency rather than eliminate it.
Product demonstrations should use an actual data lineage: a manufacturer or pack attribute should move from the accountable internal source through review, submission, authority representation, and downstream reuse. Buyers should inspect duplicate handling, terminology mapping, effective dating, rejected updates, and evidence of what the authority accepted.
What becomes independently testable
The public beta creates a new opportunity to test some retrieval and reconciliation claims without relying entirely on sales materials. It may also support market research and data-quality benchmarking, provided limitations and access terms are respected.
RegQuality Review will distinguish public API access, restricted industry access, product-data enrichment, and end-to-end regulatory workflow. These may be part of one architecture, but evidence for one does not prove the others.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
RegQuality Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.