AI server for pharmaco­vigilance: case intake, literature screening and MedDRA coding

What an AI server does in pharmaco­vigilance

An AI server for pharmaco­vigilance runs the language and document models that read safety information for a drug safety department: it turns adverse event reports from e-mail, PDFs and scanned forms into case fields for the individual case safety report (ICSR), screens the weekly literature search, suggests MedDRA terms and drafts the narrative, and a case processor approves each result in the safety database. For a marketing authorisation holder or a mid-size service provider, a server with two NVIDIA RTX PRO 6000 Blackwell Server Edition cards carries this work, since the weekly volumes fit in minutes to hours of one card by our estimates below.

Compute is rarely the limit. Validation, data separation and records decide the design more than speed does.

We wrote this for the head of drug safety or the qualified person responsible for pharmaco­vigilance (QPPV) who has to judge what such a server can take over, and for the IT team that runs it next to the safety database. The broader pharma platform, with structure models, BioNeMo and GMP Annex 11, is the subject of our guide to GPU servers for pharma and life sciences.

The four reading tasks and the rules behind them

Commission Implementing Regulation (EU) No 520/2012, Articles 25 and 28, as published on EUR-Lex; EMA GVP Module VI, Revision 2 (EMA/873138/2011 Rev 2, in effect since 22 November 2017), sections VI.B.1.1.2, VI.B.2, VI.B.7.1 and VI.B.8; read 24 October 2026. The right-hand column is our description of the AI step.

Case intake. GVP Module VI names four minimum criteria for a valid case: an identifiable reporter, a single identifiable patient, at least one suspected product and at least one suspected reaction. Reports arrive as e-mails, call notes, PDFs and scanned forms, often in several languages. A two-stage pipeline reads them, as our guide to vision-language models for document AI describes: an OCR model turns each page into text, and a language model fills a fixed case schema, with vLLM's structured outputs keeping the answer in that schema. The model also marks which of the four criteria are missing, so the case processor knows at once whether follow-up is needed. Day zero is the receipt of the information, and for a serious case the submission is due "in no case later than 15 calendar days" after it.

Literature screening. The weekly search returns hundreds or thousands of abstracts, and only some of them describe a reportable case. The model sorts each abstract into a case report about one of your products, a possible case to read in full, or not relevant, and gives its reason in one or two sentences. EMA's Medical Literature Monitoring service, based on Article 27 of Regulation (EC) No 726/2004, covers selected substances in EMBASE, International Pharmaceutical Abstracts, AMED and, since 1 April 2024, MEDLINE; for those substances and that literature, marketing authorisation holders are not required to monitor or report themselves. Everything outside it stays with the company, and that is the volume a screening model serves.

MedDRA coding. Article 25 of Implementing Regulation 520/2012 requires MedDRA, and GVP Module VI asks for coding "at the lowest level term (LLT) level". A workable design embeds the dictionary's terms once, retrieves the nearest candidates for each verbatim term from the report, and lets the language model rank them for the coder to choose. The dictionary stays on the server, and our guide to an embedding and reranker server for RAG covers the retrieval part. Check the MedDRA licence terms for its use inside your own tools.

Narratives. Article 28(3)(m) of the Implementing Regulation lists "a case narrative, where possible" among the information in a report, with the exception of non-serious adverse reactions. The model drafts it from the approved case fields, which keeps the narrative consistent with the coded data; the case processor edits and approves.

How much compute pharmaco­vigilance needs

The volumes are modest for a GPU. We size the batch work from the throughput of a published benchmark, using the example volumes below, and the interactive work from our users-per-card rule.

Writing rate about 1,907 tokens per second per RTX PRO 6000 Server Edition, our division of MLPerf® Inference: Datacenter v6.1, closed division, available category, gpt-oss-120b, offline scenario, entry 6.1-0050 (HPE ProLiant Compute DL380a Gen12, eight RTX PRO 6000 Blackwell Server Edition, 15,256 tokens per second), retrieved from mlcommons.org on 24 October 2026, result verified by MLCommons Association; per card is not an MLPerf metric. OCR at about 0.69 pages per second per card with a 5B OCR model, our estimate from our document AI guide. Volumes and tokens per item are example values. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

The benchmark's questions differ from safety abstracts and the time to read the input comes on top, so take these as orders of magnitude. They show that a weekly literature run and the normal intake fit into one night of one card. Our guide to batch LLM inference on-premise explains how such jobs are queued and run.

Interactive work is sized by memory. Case processors who ask the model about a case, or who correct a draft with it, hold a conversation on the card. By our users-per-card rule, which takes 90 per cent of the 95.6 GiB the driver reports, less 3 GiB per card and less the weights, gpt-oss-120b leaves 22.2 GiB of cache on one card, enough for 39 conversations in flight at a 16,384-token context, and 187 on a tensor-parallel pair. gpt-oss-120b is published under Apache 2.0 and its 60.8 GiB of weights fit one 96 GB card.

We build servers with two or four RTX PRO 6000 Server Edition cards for drug safety work; send us your weekly case and abstract volumes and the languages of your reports, and our team replies with a configuration.

Configuration options

The options follow the reference configurations on our AI servers page and NVIDIA's guide for certified systems: two processors, at least six cores per GPU and system memory of twice the GPU memory.

Reference configurations on our AI servers page; power by our estimate (cards at 600 W, processors, plus 15 per cent for the rest of the server).

Two cards. The entry server has two RTX PRO 6000 Server Edition, two AMD EPYC processors, 384 GB of DDR5 ECC and two NVMe drives. One card runs the validated production pipeline: OCR, the language model and the embedding model for MedDRA retrieval. The second card is split by MIG into up to four isolated 24 GB instances, as our guide to RTX PRO 6000 MIG profiles shows, for the next model version under validation, regression tests and development. The validated state of card 1 does not change while a new model is tested.

Four cards. A service provider that processes cases for several marketing authorisation holders adds a tensor-parallel pair for its case processors, about 187 conversations in flight by our rule, and keeps one card for OCR and batch runs and one for validation. Client data is separated in the safety database and in the pipeline's storage; a separate model instance per client is possible on MIG where a contract asks for it.

Two servers. Where the quality system asks for production and validation on separate machines, two two-card servers keep them apart, and either can carry the production load when the other is serviced.

The RTX PRO 6000 Max-Q is the workstation card, a 300 W blower card; in a rack it belongs only in a chassis whose maker lists it, and for continuous operation we recommend the Server Edition.

Validation, records and the EMA's view on AI

The EMA's reflection paper on AI in the medicinal product lifecycle (EMA/CHMP/CVMP/83833/2023, adopted by the CHMP on 9 September 2024) addresses pharmaco­vigilance directly. It states that "Applications within pharmaco­vigilance may allow a more flexible approach to AI/ML modelling and deployment", and that "incremental learning can continuously enhance models for classification and severity scoring of adverse event reports". The duty stays with the marketing authorisation holder: "it remains the responsibility of the MAH to validate, monitor and document model performance and include AI/ML operations in the pharmaco­vigilance system". For generative language models it warns that they "are prone to include plausible but erroneous or incomplete output" and that "quality review mechanisms need to be in place".

Implementing Regulation 520/2012 sets the frame for that system. Article 8 requires a quality system "that is adequate and effective", Article 11(1)(c) procedures that ensure "the submission of accurate and verifiable data on serious and non-serious adverse reactions", and Article 12 records that keep the information traceable, with product data and documents kept "for at least 10 years after the marketing authorisation has ceased to exist". As published in 2012, Article 26 names ICH E2B(R2) for transmission; GVP Module VI Revision 2 gives the guidance for the ICH E2B(R3) format.

EMA reflection paper EMA/CHMP/CVMP/83833/2023, section 2.3.7 and 2.3.5; Implementing Regulation (EU) No 520/2012, Articles 8, 11 and 12 as published on EUR-Lex; read 24 October 2026. The right-hand column is our reading of what an AI platform contributes; the QPPV and the quality unit decide what applies.

Which of the gateway logs, prompts and model versions count as pharmaco­vigilance records, and for how long they are kept, is a decision for the QPPV and the quality unit. Our article on AI governance with ISO/IEC 42001 maps logs and evaluation records to management-system controls, and the pharma guide linked above covers GMP Annex 11 and the draft Annex 22.

Data protection

Adverse event reports describe a person's health, which makes them data concerning health, a special category under Article 9(1) of the GDPR; the prompts, extracted fields and logs of the AI pipeline carry the same data. Large-scale processing of special categories is among the cases in Article 35(3)(b) that require a data protection impact assessment, and our guide to a DPIA for an internal LLM lists the technical inputs. Keeping the models on your own server keeps reports, abstracts with case details and logs inside your network. The legal basis is for your data-protection officer to confirm. General information on EU law as of October 2026; national rules can add conditions.

Notes for the IT team

1. Integration. vLLM serves an OpenAI-compatible API with structured outputs; the safety database or an integration layer sends documents and receives case fields as JSON. An LLM gateway with keys and a query log in front of it records who asked what.
2. Versions. Pin the model checkpoint, the serving engine, the driver and CUDA for the validated pipeline, and change them only through change control. Keep checksums of the model files.
3. Network. vLLM's --api-key protects only paths under /v1, /v2, /inference and /cohere, while routes such as /invocations and /metrics answer without the key (vLLM 0.32.0 security guide), so keep the engines on an internal network behind the gateway. The server needs no outbound internet access; new checkpoints come in through a controlled import.
4. Software on delivery. On request the server arrives with the operating system, the NVIDIA driver, CUDA and a container runtime. Run your own acceptance test of the delivered system, as our guide to GPU server acceptance testing describes, and record the results for the qualification.

Our Private AI/ML service sets up the intake pipeline, retrieval for MedDRA and the logging on these servers, with engineering by our partner Vixen.UNO; describe which of the four tasks you would start with, and we propose a pilot on past cases and the server for it.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build AI servers to order with two or four RTX PRO 6000 Server Edition cards, assembled and tested before delivery, delivered anywhere in the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Our Private AI/ML service deploys the models and connects them to your systems. Validation and the release of the system for pharmaco­vigilance use stay with your QPPV and quality unit. Our guide to buying a server with two RTX PRO 6000 Server Edition lists the entry configuration.

FAQ