Coding is where automation in pharmacovigilance is most mature, most measurable, and most consequential to get subtly wrong. It looks like a lookup problem — take the reported text, find the matching term — and it is not. Reporters do not write in dictionary terminology, one phrase frequently contains several distinct events, and the correct answer depends on which dictionary version was in force.
This guide covers how auto-coding actually works, the specific linguistic problems it has to solve, why version management matters more here than almost anywhere else in the case record, and what a coder must still own.
The dictionary is licensed content
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.
MedDRA is a hierarchical terminology. Without going into the terminology itself, the structural point that matters for coding practice is that terms exist at several levels of specificity, and coding decisions interact with how data is later retrieved and analysed.
| Level | Role in coding and analysis |
|---|---|
| Lowest Level Term (LLT) | The most specific level, closest to how the event was actually reported. Cases are commonly coded here to preserve the reported nuance |
| Preferred Term (PT) | The level at which most reporting, tabulation and signal detection is performed. Each LLT links to a PT |
| High Level Term (HLT) | Groups related PTs for analysis |
| High Level Group Term (HLGT) | A broader grouping used for aggregation |
| System Organ Class (SOC) | The top level, used for presenting summary tabulations in periodic reports |
Why level choice has downstream effects
Coding too specifically or too generally changes what your signal detection and periodic tabulations show. Coding a set of symptoms individually rather than coding the diagnosis a clinician would recognise can fragment a genuine safety picture across several terms — one of the reasons medical review, not just QC, needs to look at coding.
The difficulty is linguistic, not clerical. These are the specific problems any auto-coding approach has to handle, and they are the reason simple dictionary lookup was never sufficient.
Vocabulary mismatch
Reporters write "threw up", "couldn't stop being sick", "emesis". Consumers, HCPs and literature authors use entirely different registers for the same event.
Multiple events in one phrase
"Rash, itching and swelling of the face after the second dose" is three or four separate coded events, not one — and splitting it correctly is a judgement.
Negation and hypotheticals
"No signs of infection" and "we were worried about a possible reaction" must not become coded events. Naive matching codes both.
Symptom versus diagnosis
A reported list of symptoms may correspond to a diagnosis a clinician would recognise. Which to code is a clinical decision with analytical consequences.
Misspellings and abbreviations
Free-text intake produces typos, local abbreviations and non-standard shorthand at high rates, particularly from consumer channels.
Language and translation
Multi-market intake means source text in several languages, where translation choices affect the coded outcome.
Temporality and context
Medical history, concomitant conditions and the adverse event itself are all clinical text in the same document — coding must attach the term to the right context.
Severity mixed into the term
"Severe headache" mixes an event with a severity qualifier that generally belongs in a separate structured field.
Practical implementations layer several techniques, because each catches what the previous one misses. Understanding the layers helps you interpret why a given proposal was made — and why confidence differs between cases.
| Layer | What it does | Limitation |
|---|---|---|
| Exact match | Direct match of verbatim text against dictionary terms | Only works when the reporter happened to use dictionary language |
| Synonym and alias lists | Maps known lay and clinical variants to terms, often curated over time | Only covers variants someone has already added |
| Normalisation | Handles case, punctuation, plurals, spacing and common misspellings | Mechanical only — no understanding of meaning |
| Historical match reuse | Reuses previously accepted codings of the same verbatim text | Propagates any earlier error consistently — powerful and therefore risky |
| Semantic / model-based matching | Matches on meaning rather than surface form, handling paraphrase and unusual phrasing | Probabilistic; needs confidence scoring and review |
| Context handling | Detects negation, hypotheticals, medical history versus event, and splits multi-event phrases | The hardest part; imperfect and the main reason review remains necessary |
Historical match reuse deserves specific attention
Reusing previously accepted codings is efficient and improves consistency — which is exactly why an error in an accepted coding propagates silently across every subsequent case with that verbatim text. Any implementation using this should let you correct a historical mapping centrally and identify the cases already coded from it.
MedDRA is updated periodically, and the update is not cosmetic — terms are added, and the status of existing terms can change. This has direct consequences for a safety database, and it is the aspect of coding most likely to produce an audit finding.
- Every coded case should record which dictionary version it was coded against — without this, the coding cannot be interpreted or defended later
- Version upgrades should be controlled and deliberate, applied by an administrator rather than happening implicitly
- Recoding or impact assessment on upgrade needs to be planned: which cases are affected, what is recoded, what is left as coded, and on what basis
- Submissions must represent the dictionary version consistently, since the receiving authority interprets terms against a version
- Aggregate reports and signal detection compare data across time, so a version change mid-interval needs to be understood rather than discovered when numbers move
- The upgrade itself is a change to a qualified system and should follow change control, with the assessment documented
The question an auditor asks
"Which MedDRA version was this case coded against, and which version was in force when the listedness assessment was made?" If the system cannot answer both from the record, the coding and the expectedness determination are both difficult to defend — which is why version control is not an administrative nicety.
Auto-coding produces proposals. What makes the proposal safe is the handling around it.
| Mechanism | Why it matters |
|---|---|
| Per-term confidence | Lets low-confidence terms be routed to review individually, rather than trusting or re-checking the whole case |
| Verbatim preserved alongside the code | The reported text must remain in the record; the coded term does not replace it |
| Manual override on any term | The coder must always be able to change a proposal — with no configuration that prevents it |
| Override recorded with attribution | What was proposed, what it was changed to, by whom, when — this is your evidence that review is real |
| Multi-event splitting visible | The reviewer needs to see how one verbatim phrase became several coded terms and be able to adjust it |
| Version enforcement | Coding always against the administratively controlled current version, never an ad-hoc one |
| Medical review of clinical appropriateness | QC checks convention; a clinician checks whether the term represents the event — see medical review versus quality review |
The boundary
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.
For the distinction between coding conventions checked at QC and clinical appropriateness assessed at medical review, see medical review versus quality review.
Coding is unusually measurable, which makes it a good place to demonstrate whether your automation is genuinely working.
| Metric | How to interpret it |
|---|---|
| Auto-coding proposal rate | The share of terms for which a proposal was produced at all. Low rates point at source quality or synonym coverage |
| Override rate | The share of proposals a coder changed. Very high means the model or synonym coverage is weak; very low may mean reviewers are accepting uncritically |
| Override reasons distribution | More useful than the rate: wrong level, wrong term, missed event, spurious event from negation each imply a different fix |
| Coding consistency across coders | The same verbatim coded differently by different people indicates a conventions or training gap |
| Terms changed at medical review | Points specifically at clinical appropriateness rather than convention — often the symptom-versus-diagnosis question |
| Missed events (found later) | Events present in the narrative but never coded. The most serious coding failure, because it is invisible in the structured data |
| Cases coded against a superseded version | Should be structurally impossible; any occurrence is a control failure rather than a metric to trend |
The metric that hides the worst failure
Override rate tells you about terms that were proposed. It says nothing about events in the narrative that were never coded at all — and a missed event is worse than a mis-coded one, because the structured data gives no hint that anything is absent. Catching this is precisely why the narrative-versus-data comprehension check at QC cannot be automated away.
Product coding runs alongside event coding and has its own characteristic difficulties, which are structural rather than linguistic.
- Brand name versus active substance, with the same brand meaning different formulations in different markets
- Combination products, where the reported name maps to several active substances
- Strength, form and route variants of the same product
- Local and historical brand names that no longer match current market authorisations
- Distinguishing suspect from concomitant medication — a case attribute, not a coding one, but frequently conflated during entry
- The same version-management discipline as MedDRA: record the version, upgrade under control
In PVgenix, MedDRA and WHO Drug Dictionary versions are managed centrally by an administrator, auto-coding proposes terms against the controlled version, manual override is available on every term and recorded on the audit trail, and the reported verbatim is preserved alongside the coded term. Dictionaries themselves are licensed by the client. See case processing and assessment.
The short version
Auto-coding works well because coding is a language problem with a verifiable answer — but the hard parts are negation, multi-event phrases, and symptom versus diagnosis, which is why proposals need per-term confidence and a coder who can override anything. Record the dictionary version on every case, upgrade under change control, and watch for missed events rather than only mis-coded ones.
Also in this cluster: AI in pharmacovigilance for the assistance-versus-decision boundary, and AI versus manual ICSR processing for where coding sits in the overall effort picture.
Frequently asked questions
Common questions
It layers several techniques. Exact matching catches verbatim text that happens to use dictionary language; curated synonym and alias lists map known lay and clinical variants; normalisation handles case, punctuation, plurals and common misspellings; historical match reuse applies previously accepted codings; semantic or model-based matching handles paraphrase and unusual phrasing; and context handling detects negation, distinguishes medical history from the event, and splits phrases containing multiple events. Each layer catches what the previous one misses, and the output is a proposal with a confidence score rather than a decision.
The difficulty is linguistic. Reporters do not use dictionary terminology, and consumers, healthcare professionals and literature authors use different registers for the same event. One phrase often contains several distinct events. Negation and hypotheticals must not become coded events. A list of symptoms may correspond to a diagnosis a clinician would recognise, and which to code is a clinical decision. Add misspellings, abbreviations, multiple source languages, and severity qualifiers mixed into the reported term.
Because MedDRA is updated periodically and terms can be added or have their status changed, a coded term can only be interpreted against the version it was coded under. Every case should record its dictionary version. Version upgrades should be applied under administrative control with a documented impact assessment covering what is recoded and on what basis, submissions must represent the version consistently, and aggregate reporting and signal detection comparisons across time need to account for a version change. An auditor will ask which version a case was coded against.
Always, on any term, with no configuration that prevents it — and the override should be recorded with what was proposed, what it was changed to, by whom and when. That record is the evidence that review is real rather than nominal. The reported verbatim text must also be preserved alongside the coded term; the code supplements the reported text rather than replacing it.
There is no universal target, and the rate alone is less informative than the reasons behind it. A very high override rate suggests weak synonym coverage or a poorly fitting model; a very low rate may indicate reviewers accepting proposals uncritically. What is genuinely useful is the distribution of override reasons — wrong level, wrong term, missed event, spurious event from negation — because each implies a different corrective action.
A missed event — an adverse event described in the narrative that was never coded at all. It is worse than a mis-coded term because the structured data gives no indication that anything is absent, so it will not appear in tabulations, signal detection or submissions. Override-rate metrics cannot detect it, since they only measure terms that were proposed. This is why the narrative-versus-structured-data comprehension check during quality review remains a human step.
Yes. Third-party dictionaries and licensed content, including MedDRA and the WHO Drug Dictionary, are procured and licensed by the client. A software provider integrates them — including version management, auto-coding and override handling — but does not supply or license them. Budget for these separately when comparing total cost across vendors.