Extracting Adverse Event Details From a Pharmacovigilance Report

This page is about the fields on a pharmacovigilance report and how to get them out of a document intact. It is not about deciding whether a drug caused an event. That judgement belongs to qualified assessors, and the single most important property of a good extraction here is that it does not quietly make that judgement on their behalf.

What makes a report a report

An individual case safety report is considered valid for reporting purposes when four elements are identifiable: a patient, a reporter, a suspect product, and an event. Reports arrive missing one of these all the time — a call centre note with no reporter contact details, a literature abstract with no patient identifier beyond an age — and whether a case is valid determines whether it enters the reporting workflow at all.

That gives the extraction a job before any field-by-field work: assess presence of the four minimum elements and report it as a document-level status. It is a completeness gate rather than a content extraction, in the same way the signature check on a consent form is separate from reading the form. And “identifiable” is weaker than “identified”: an initial and an age can make a patient identifiable for these purposes, so the check is for the presence of some identifying element rather than for a complete demographic record.

The source documents vary widely. A completed MedWatch form has lettered sections — patient information, adverse event or product problem, suspect products, suspect medical device, reporter details, and manufacturer-use sections — which give you a field-mapped starting point. A CIOMS form has its own numbered boxes. A spontaneous report transcribed from a phone call is unstructured prose. A literature case report is a journal article. Only the first two have anything resembling a form layout, and a pipeline that assumes one will fail on the majority.

Reporter, event, outcome

Three field groups carry most of the value, and they are routinely collapsed into each other by careless extraction.

• Reporter. Who reported, and critically their qualification — physician, pharmacist, other health professional, consumer, lawyer. The qualification is a field in its own right because it affects how the report is weighted and, in some regimes, what follow-up is required. Reporter is also distinct from the patient even when they are the same person, and distinct again from the sender of the document.
• Event. What happened, as described. There may be several per report and each carries its own start date, stop date, seriousness and outcome. Modelling one event per report is the structural error that costs most, because a case with three events where one is serious is not the same as a case with one event.
• Outcome. A closed vocabulary, not free text. Reporting standards use a fixed set along the lines of recovered or resolved, recovering or resolving, not recovered, recovered with sequelae, fatal, and unknown. Extract into that enum, and treat “unknown” as a real value rather than as a missing one — it is the correct answer for a large share of spontaneous reports and coercing it to null loses the distinction between an unanswered question and an answered one.

Seriousness is a fourth field and it is a term of art, not an opinion about severity. Under the US postmarketing reporting regulation at 21 CFR 314.80, a serious adverse drug experience is one resulting in death, a life-threatening experience, inpatient hospitalisation or prolongation of an existing hospitalisation, a persistent or significant disability or incapacity, or a congenital anomaly or birth defect — with a further provision for important medical events that may jeopardise the patient and may require intervention to prevent one of those outcomes. It is a checkbox set on most forms, and it should be extracted as a set of booleans, one per criterion, rather than as a single serious-or-not flag. A severe headache is not serious; a hospitalisation for observation is.

Expectedness is a fifth, and it is not a property of the event at all — it is a comparison between the event and the current approved labelling for the product, which is why this cluster’s package insert page is next door. Do not attempt to derive it during extraction. Transcribe the reporter’s or the assessor’s stated position if the document carries one, and leave the determination to the process that owns it.

Causality is a separate field with an owner

Reports frequently carry a causality assessment: a statement about whether the product is thought to have caused the event. It may be the reporter’s view, the manufacturer’s, or both, and the two can differ — which is precisely why reporting formats provide for both and why they must not be merged.

The extraction rule that follows is simple and load-bearing. Causality is a field with three parts: the assessment, the assessor, and the method or scale used if one is named. It is never part of the event description. When a narrative reads “patient developed a rash two days after starting therapy; the reporting physician considered it probably related”, the event field gets the rash and its timing, and the causality field gets the assessment attributed to the reporting physician. Putting the whole sentence in the event description creates a record in which an opinion is indistinguishable from an observation, and downstream aggregation then counts opinions as events.

The inverse error is worse and is the one a language model will happily commit: inferring causality that the document does not state. A model asked to fill a causality field on a report that contains no assessment will produce one, because that is what filling a field means. Constrain the field to a closed enum that includes an explicit not_assessed member, require the assessor to be named whenever the assessment is not not_assessed, and reject any output where an assessment appears without a supporting span in the source text. Requiring a source span for every non-null field is a general defence against confident invention, and it earns its keep here more than anywhere.

Verbatim terms and coded terms

Safety data is coded to a standard terminology so that reports can be aggregated — the same clinical concept described three ways by three reporters has to become one term to be countable. Coding is done against a controlled dictionary, and the coded term is derived from the reporter’s words by a person or a tool that owns that step.

Extraction must preserve the reporter’s words unchanged. The verbatim term is the record; the coded term is an interpretation of it, and the two live in separate fields. A pipeline that has a model “normalise” the event description to standard terminology has destroyed the source and pre-empted a controlled process, and it has done so invisibly, because the output looks tidier than the input. Keep event_verbatim exactly as written, including the awkward phrasing and the misspelling, and leave event_coded null for the coding step to fill.

Dates, narratives and handling obligations

Dates on these reports are frequently partial. A reporter knows the month but not the day, or the year only. Reporting formats accommodate partial dates explicitly, so your schema must too: store a date with a precision field taking values of year, month or day, rather than fabricating the first of the month to make a date type happy. Timeliness calculations depend on these — serious and unexpected postmarketing reports carry a 15 calendar day clock from initial receipt of the information under 21 CFR 314.80 — and a fabricated day silently moves a deadline.

The narrative is the field most likely to contain identifiers that should not travel. Free-text case narratives routinely include names, dates of birth, hospital record numbers and clinician names embedded mid-sentence, and none of that is needed to extract the structured fields. Redact before the document leaves your infrastructure, not after — the general techniques are on the redaction page — and treat the model provider as a processor of personal data with the contractual terms that implies, since a case narrative is health information about an identifiable person wherever you are.