The Reporting Rules Engine: How a Case Becomes a Submission

◇◇ Learning · why this runs before everything else

Not every case is a plain patient took drug, had reaction. Some cases carry a special category that changes which rules even apply — before you ever get to seriousness or expectedness. This gate classifies the case first, so Gate 1 onward evaluates it with the right rule set instead of the generic one.

◆◆ In practice · the categories and why each is special

Each of these categories has a genuinely different regulatory path, not just a label:

▹▹ Building it · how to approach it

Run a classifier immediately after case lock, before Gate 1: derive the category (or categories — combination product and pregnancy can co-occur) from the case data, then look up two booleans per destination-and-category pair: include and override. If include=false for a category on this destination, the case skips Gate 1 for that destination entirely and is logged as not evaluated — category excluded, not silently dropped. If include=true, hand the case to Gate 1 onward — but tag which category triggered it, since combination-product and pregnancy cases carry extra sub-rules (malfunction-only timing, registry routing) that a plain drug case doesn't.

• ▸Store category rules as data per destination, exactly like the other gates — never branch in code per category name.
• ▸A case can match more than one category (e.g. combination product and pregnancy-with-AE); evaluate every matching category's sub-rules, don't just pick one.
• ▸Log the category match and the include/override decision in the same evaluation log used by the other gates, so an auditor sees why a case was or wasn't evaluated for a destination.

◇◇ Learning · why each field

The regulator cares about one thing: is this a new, important safety signal? Three fields decide it.

• ▸Seriousness — did something bad enough happen? Death, life-threatening, hospitalisation, disability, congenital anomaly, or other medically important condition.
• ▸Expectedness — is this reaction already in the product's reference document (label / SmPC / IB)? Already listed = expected. Not listed = unexpected = new information.
• ▸Causality — is the drug reasonably suspected? For spontaneous post-market cases the bar is low; for trials you need a reasonable possibility that cannot be ruled out.

◆◆ In practice · the decision logic

The classic reportable combination is Serious + Unexpected + (Related where required) — the SUSAR of clinical trials, and the 15-day Alert of post-marketing.

▹▹ Building it · how to approach it

Treat reportability as one self-contained decision that takes a case plus an authority's profile and returns a clear verdict with a reason attached — never scattered through screen logic. Expectedness is a comparison of each reaction against the product's reference safety list, loaded per product — never a list baked into the program.

• ▸First the validity gate — if the four minimums aren't all present, stop immediately with an invalid-case reason.
• ▸Then read three things: is it serious, is any reaction unexpected against the product's reference document, and is it causally related.
• ▸For a trial case all three must hold (a SUSAR); for a spontaneous post-market case, causality is presumed from the suspect-drug role, so the relatedness gate is a per-authority toggle — off for post-market, on for trials.
• ▸Always hand back a reason, not just yes or no — serious & unexpected versus aggregate only — because the audit trail lives on it.

◇◇ Learning · why each field

One case can owe several submissions — one XML per obligated authority. The question, per authority: given where it happened, where the product is sold, and what kind of case it is — do we owe this authority a report?

• ▸Country of occurrence — where the event physically happened.
• ▸Product ↔ authorisation — is this product actually marketed in that country? No authorisation usually = no obligation.
• ▸Case type — trials route to trial authorities, spontaneous to the PV system.

◆◆ In practice · the where-to-report matrix

Build it as a matrix of (authority) × (conditions) → (yes/no + format + gateway + timeline). Keep post-market and clinical-trial as two separate matrices — different databases, different clocks.

▹▹ Building it · implementation

Routing walks the list of authorities, tests each one's conditions, and collects the destinations that qualify. Each rule is stored as data, not written into the program: a set of conditions (product marketed in the US, spontaneous, serious, unexpected) paired with an action (use the E2B(R3) format with the FDA profile, send through the FDA gateway, set a 15-day clock). Design principle: the engine is a matcher; the rules are data. Adding a partner or a country means adding a rule entry, not editing the engine.

◇◇ Learning · why each field

Every case has one worldwide case ID (C.1.1) that never changes. What changes is the version.

• ▸Initial — first time this case is sent to that authority.
• ▸Follow-up — same case ID, new info arrived, message number increments.
• ▸Nullification — please delete this case, it was invalid/duplicate.
• ▸Amendment — case valid, but a field was wrong; here's the correction.

▹▹ Building it · how to approach it

The decision keys off the submission history for this case-and-authority pair. If the case has never been sent to that authority it is an initial report; if it is being withdrawn, a nullification; if a field is being corrected, an amendment; otherwise a follow-up — which then goes to the significance check before anything is generated. Keep a running submission history per case per authority; the worldwide case identifier stays constant everywhere while a separate message counter steps up on every follow-up.

▹▹ Building it · how to approach it

Significance is a comparison of the current case against the version last submitted to that authority. Each field carries a rule for what counts: a reaction added or removed, seriousness moving up, a newly met seriousness criterion, causality shifting toward related, a suspect drug added or changed, an outcome worsening. If any changed, generate the follow-up; if nothing on that list moved, it is not significant.

• ▸Freeze a copy of each case exactly as it was submitted, so the comparison is against what the authority actually received — not an in-between edit.
• ▸Record which field triggered significance. Auditors ask both why you resubmitted and why you didn't.

◇◇ Learning · what a downgrade means

New information can lower a case's status, not just raise it. Three common downgrades:

• ▸Downgrade to Non-Serious — the case no longer meets any seriousness criterion (e.g. the hospitalisation turned out to be a routine visit).
• ▸Downgrade to Serious-Expected — still serious, but the reaction is now found to be listed in the reference document, so it is no longer a 15-day / expedited unexpected case.
• ▸Downgrade to SAE — a SUSAR that loses its unexpected or causal basis and becomes an ordinary serious adverse event.

▹▹ Building it · how to approach it

Downgrades are just significance rules that fire in the opposite direction — build them as first-class entries in the same significance list, not as an afterthought. Each still produces a follow-up transmission and carries its own reason code (DOWNGRADE_TO_NONSERIOUS, DOWNGRADE_TO_SERIOUS_EXPECTED, DOWNGRADE_TO_SAE). A downgrade can change which onward path the case takes — a case that drops to non-serious may leave the expedited queue entirely and feed only aggregate reports from that point on. Record the transition so the audit trail explains why the expedited clock stopped.

◇◇ Learning · Day 0

The clock starts at Day 0 = the date anyone in the company first received the four minimum criteria — not when the case was entered or locked. From Day 0 you count calendar days.

▹▹ Building it · how to approach it

The due date is the start date plus the applicable number of days, then rolled forward to the next working day if it lands on a weekend or holiday.

• ▸Run a separate clock per destination — the FDA and EMA windows can differ for the same case.
• ▸Drive escalation off how many days remain: amber when the window is closing, red once it's overdue.
• ▸The EMA measures compliance from receipt to the moment it hits the gateway — so capture the gateway timestamp, not just when you generated the file.

◆◆ In practice · when this matters

By default a case due date follows the FDA or EMA rule for its criteria. But a trial's protocol or its agreement with the agency may set different expedited windows for that study only. Without an override, the system would apply the generic clock and either over- or under-report against what was actually agreed for that trial.

▹▹ Building it · how to approach it

Add a thin override layer in front of the timeline lookup. When resolving the window for a destination, first check whether the case's study registration has an override flag set; if it does, take the study's 7-day / 15-day values, otherwise fall back to the authority profile. Keep it as data on the registration — a boolean plus the two day-values — never a code branch per study, and record which source supplied the window (study override vs profile) in the evaluation log.

▹▹ Building it · how to build both

• ▸Inheritance / base rule set — a rule set can name another as its base and inherit all its rules, then add or override its own. Resolve rules at the lowest level of inheritance: a child rule beats the base; an override to blank clears an inherited value.
• ▸The empty set is a feature, not a gap — assigning an empty rule set must deterministically yield no transmissions; the engine treats matched a rule set with zero rules as a valid, logged no-destination outcome, not an error.

◇◇ Learning · why OLT exists

When a product or study registration is being made inactive, there can still be one final obligation to send an outstanding case to that authority before the door closes. Treat One Last Time as a standard rule (as in the EMA rule set), not an optional extra.

▹▹ Building it · how to approach it

Tie OLT to the registration's lifecycle. When a registration transitions to inactive, run one final evaluation pass over open cases for that destination: anything still owed generates its last transmission, then the destination stops matching future cases. Carry a distinct reason code (ONE_LAST_TIME) so the audit trail shows the report was a lifecycle-close, not an ordinary follow-up.