Pre-built pharmacovigilance libraries for the parts nobody wants to rebuild
E2B(R3) XML generation and schema checking, MedDRA and WHO Drug Dictionary coding, the regulatory clock, the reporting rules engine, CIOMS I and MedWatch output. Licensed as APIs and components you call from your own system, with the specification and traceability documentation behind each one.
- Exchange formats
- E2B(R3), E2B(R2), CIOMS I, MedWatch
- Terminologies
- MedDRA, WHO Drug Dictionary
- Integration
- REST APIs, system-to-system feeds
- Per component
- FS, DS, RTM and test evidence
What a pharmacovigilance API gives you that a platform does not
A pharmacovigilance API is a licensed software component that performs one standards-heavy safety function — generating an E2B(R3) XML file, checking it for schema conformance, coding a verbatim term to MedDRA, calculating a reporting due date — and returns the result to whatever system called it. You keep your own application, your own database and your own user interface. You stop owning the regulatory plumbing underneath them, and you stop rewriting it every time a schema version or a regional business rule changes.
- Use only the components you need, in the system you already have
- No migration, no data move, no change to how your users work
- Each component ships with its Functional and Design Specification, a Requirements Traceability Matrix and test evidence
- Schema and rule updates arrive as component releases rather than as a project on your backlog
- Available as hosted REST APIs or as components deployed inside your own environment
For teams that already have a system
If you are choosing a safety database, this is the wrong page — the platform is cheaper and faster than assembling one. These are the three situations where components are the better buy.
Product teams with an in-house safety build
Your system works and your users know it. What hurts is the standards work: a new E2B schema version, a changed regional rule, a MedDRA release. Those are the parts to hand over.
Adjacent platforms adding safety features
A LIMS, a clinical data platform, a regulatory document system or a patient-support tool that now needs to emit a compliant ICSR. You need one capability, not a second database.
CROs and MAHs with a system they must keep
Replacing a qualified system is a project nobody wants to fund. Adding a component to it, with its own specification and traceability, is a change you can actually get through change control.
The components available to license
Each is a discrete capability drawn from the platform's own codebase, not a demo library written for this page. Scope is agreed per client — most engagements start with two or three.
E2B exchange and form output
The component most teams come for. Generation and schema checking in both current exchange standards, plus the human-readable forms regulators and partners still ask for.
- E2B(R3) XML generation and schema conformance checking
- E2B(R2) generation and checking, for partners still on it
- CIOMS I and FDA MedWatch (3500A) form generation
- Acknowledgement (ACK) parsing and reconciliation
- Built-in AS2 gateway, so no third-party gateway licence is needed
Coding and terminology
Auto-coding with manual override, and the version management that keeps a coded case defensible after a dictionary release.
- MedDRA coding with admin-controlled version management
- WHO Drug Dictionary coding and maintenance
- Auto-coding with mandatory review gates on low-confidence items
- Configurable code lists and picklists
- Licences for MedDRA and WHO-DD are procured by you
Regulatory clock and reporting rules
The logic that decides what is due, to whom, and when. This is where in-house builds accumulate the most undocumented exceptions.
- Day 0 determination and expedited timeline calculation per region
- Due-date tracking and late-submission alerting
- Configurable rules engine: which authority, which format, which timeline, from case attributes
- Study versus spontaneous and market-specific rule handling
- FDA, EMA and MHRA submission routing support
Case assessment and intake
The assessment logic and the intake surface, for teams whose own system holds the case but not the reasoning around it.
- Seriousness and ICH severity auto-flagging
- Causality assessment: WHO-UMC and company algorithm
- Expectedness against version-controlled CCDS, SmPC and USPI
- Duplicate detection and case versioning
- AI-assisted extraction from PDFs, emails and narratives, with confidence scoring and human review routing
- API-based intake for system-to-system feeds
Surveillance and analytics
Statistical surveillance for teams that hold the case data already and need the methods on top of it.
- Disproportionality: PRR, ROR, BCPNN/IC and EBGM
- Masking detection
- Configurable thresholds and signal review workflow
- Line listings and summary tabulations
The documentation behind each component
What makes a component something your QA team can accept rather than a dependency they have to argue about.
- Functional and Design Specification per component
- Requirements Traceability Matrix
- Test evidence and, where relevant, load-testing reports
- IQ / OQ / PQ material for components deployed in your environment
- Full audit logging of every component call, with before and after values
Standards and formats covered
The specific question a developer asks first. If a format you need is not listed, say so on the call rather than assuming it is implied.
| Standard or format | What the component does | Typical use |
|---|---|---|
| E2B(R3) | Generates ICH E2B(R3) XML from your case data and checks the output for schema conformance before it leaves your system. | EudraVigilance and FDA submission, partner exchange, and any regulator that has moved to R3. |
| E2B(R2) | Generates and checks E2B(R2) XML, and converts between R2 and R3 field structures where a mapping exists. | Licence partners and regions still exchanging in R2, and migration off a legacy system. |
| CIOMS I | Renders a completed CIOMS I form from the case record. | Partner and investigator distribution, and regulators that still accept the form. |
| FDA MedWatch 3500A | Renders the MedWatch 3500A output from the same case record. | US reporting paths where the form rather than the XML is expected. |
| MedDRA | Codes verbatim terms with admin-controlled version management, auto-coding, and manual override with an audit trail. | Event, indication and medical-history coding. You license MedDRA. |
| WHO Drug Dictionary | Codes products against WHO-DD, with the same version control and override behaviour. | Suspect and concomitant product coding. You license WHO-DD. |
| AS2 gateway | Transmits and receives over AS2, including acknowledgement handling and reconciliation. | FDA ESG and EudraVigilance gateway traffic, without a separate gateway licence. |
| Reporting rules | Evaluates case attributes against configurable rules to decide the authority, format and timeline, and calculates Day 0 and due dates. | Expedited reporting decisions across multiple markets and study types. |
| Reference safety information | Holds version-controlled CCDS, CCSI, SmPC and USPI and runs listedness comparison against them. | Expectedness determination that drives whether a case is expedited. |
| Signal statistics | Computes PRR, ROR, BCPNN/IC and EBGM over the case data you supply, with masking detection. | Routine disproportionality surveillance where volume supports it. |
A component checks output against the published schema and against the rules you configure. It does not decide whether those rules are the right ones for your products and markets — that determination stays with your qualified PV personnel, and a component that claimed otherwise would be selling you a compliance guarantee no software can give.
How a component engagement runs
Short, because it has to be: the whole reason to license a component rather than a platform is that it should not become a programme.
- Step 1
Technical scoping
Which components, which formats, and what your case data looks like today. We ask for a sample payload early, because field coverage is where integrations actually stall.
- Step 2
Interface agreement
The request and response contract is written down and the field mapping from your schema to ours is agreed, along with whether the component runs hosted or inside your environment.
- Step 3
Sandbox integration
You build against a sandbox with synthetic data and no live transmission. Generated files can be checked end to end before anything reaches a gateway.
- Step 4
Documentation and go-live
FS, DS, RTM and test evidence handed over for your change control. Your QA team runs qualification of the change in your environment, then the component moves to production traffic under the agreed SLA.
Three licensing shapes
Chosen mostly by where the component has to run and how much of your traffic goes through it.
Hosted API
Most commonTeams that want to call an endpoint and be done. Nothing to deploy or patch on your side.
- REST endpoints for the components in scope
- Sandbox plus production environments
- Hosting, patching and uptime handled by PVgenix
- Audit logging of every call
- Schema and rule updates delivered as releases
Quoted per component, per year, with volume bands on call or case throughput.
Deployed in your environment
Data-residency or isolation requirements that rule out sending case data to a third-party endpoint.
- Components deployed inside your own infrastructure
- No case data leaves your environment
- IQ / OQ / PQ material for the deployed components
- Release channel for schema and rule updates
- EU, US or India region options where we host the environment
Quoted as a one-time integration and setup fee plus an annual component licence.
Component plus build
Cases where the component covers most of it but your system needs work to meet it in the middle.
- Everything in one of the models above
- Engineering time to build the integration on your side
- Field mapping and data-migration tooling where needed
- A named engineer through the integration
Quoted as the component licence plus engineering time — see the drug safety software development page for how that is structured.
No rate card is published, deliberately. Component pricing turns on which components you take, whether they run hosted or in your environment, and your case or call volume — and a figure invented for a web page is one we would have to correct on the call. Send a sample payload and your volume, and you get a real quote.
What these components are not
They are not a compliance guarantee. A component generates output that conforms to a published schema and applies the rules you configure. Whether those rules correctly reflect your products, markets and obligations is a pharmacovigilance determination owned by your qualified PV personnel. PVgenix provides software development, not regulatory advice.
They are not a substitute for a safety database. A component holds no case lifecycle, no workflow, no review gates and no retention policy of its own. If you do not already have a system, assembling one out of components will cost more and take longer than licensing the platform.
They do not arrive qualified for your environment. Each component ships with its specification, traceability matrix and test evidence, plus IQ/OQ/PQ material where it is deployed on your side. Qualification of the change in your environment goes through your own change control.
They do not include MedDRA, the WHO Drug Dictionary or any other licensed terminology. You procure and license those; the coding components integrate them.
They are not an open-source library or a code sale. You license a supported, versioned component with a release channel behind it, which is the difference between a dependency that keeps up with schema changes and a snapshot that quietly stops being correct.
Answers before the call
The questions that come up in most scoping conversations. If yours is not here, ask it on the call.
Browse the full FAQYes. Components are licensed individually and E2B exchange is the most common single-component engagement: XML generation from your case data, schema conformance checking before the file leaves your system, and acknowledgement parsing on the way back. Most teams add the reporting rules engine and the regulatory clock within a year, because that is where the next set of exceptions accumulates.
Both. R3 generation and schema checking is the default, R2 is supported for licence partners and regions still exchanging in it, and conversion between R2 and R3 field structures is available where a defensible mapping exists. Some R3 fields have no R2 equivalent, so a conversion is a mapping decision rather than a lossless transform, and the mapping is documented so your QA team can review it.
On the hosted model, the payload is transmitted to the PVgenix API, processed, and returned; every call is captured in an audit log with before and after values. If sending case data outside your infrastructure is not acceptable — commonly the position under GDPR or a sponsor contract — the same components can be deployed inside your own environment, and EU, US and India region hosting options exist where we host it.
It arrives as a component release rather than as a project on your backlog, which is the main reason teams license these rather than maintain them. You get the updated component, the revised specification and traceability material, and a window to run it through your own change control. What you do not get is a surprise: changes are versioned and released, not applied silently underneath a live integration.
PVgenix is validation-ready and audit-ready: it ships with a complete IQ/OQ/PQ documentation package to support client-led validation. 'Validated' is a state achieved only after qualification is executed in a specific client environment.
Third-party dictionaries and licensed content - including MedDRA and the WHO Drug Dictionary - are procured and licensed by the client. PVgenix integrates them into the application.
Yes — the extraction component is licensed separately from the deterministic ones, and plenty of engagements take E2B and coding without it. Where it is used, it works the same way it does in the platform: extraction from PDFs, emails and narratives, with confidence scoring that routes low-confidence items to a human reviewer before anything is accepted.
AI assists intake and data entry. Qualified personnel review, edit, and approve AI-generated content before a case proceeds; regulated judgments remain with the client's PV personnel.
That is the expected route. Integration runs against a sandbox with synthetic data and no live transmission, so you can generate files, check them end to end and confirm field coverage against your own schema before anything touches a gateway or a licence is signed for production volume. Bring a representative sample payload to the scoping call; field coverage is where integrations stall, and it is cheaper to find that out in week one.
Send us a sample payload
Tell us which components you need, whether they must run inside your environment, and what your case volume looks like. We will come back with the interface contract, the field mapping questions, and a real figure.