Your safety database.

Every wording is kept. Edits are audited like any other field, so the narrative as it stood before a change can be recovered — which matters, because the narrative is the part an assessor reads first and the part most often revised after medical review.

You upload the SmPC and code its listed terms once. From then on, when a case records a reaction, the system tells you whether it is already listed — against the version in force on the date of the reaction, not the one in force today, which is the distinction an assessor challenges. It matches down the MedDRA hierarchy, so an SmPC that says hepatic disorders catches a case coded cholestatic hepatitis.

It proposes; you decide. Expectedness is never stored without who decided it and why, and the system's answer is kept beside yours. Where nothing matches it says so rather than guessing unlisted — because it cannot tell a term that is not in the SmPC from an SmPC nobody has uploaded, and those are different facts.

It flags it. The same SmPC carries the authorised indications, so when a case records an indication that is not among them, you get told — with the authorised list next to it. Use outside the authorised indication is a reportable special situation, and it is the kind of thing that is easy to miss by eye.

It is a flag, never a conclusion: the indication may simply have been recorded loosely. Accepting it and dismissing it both leave a record of who did it.

It becomes a new version linked to the previous one, with the chronology visible from the case. Significant new information opens a new 15-day clock from the date you received it, and the change of due date is recorded.

The second save is rejected, and you are shown what changed while you were editing. Nothing is ever overwritten silently — a quietly lost edit is the kind of thing you only discover during an audit.

Yes. The stages, who may move a case between them, and a separate route per case type are all configurable. Reporting timelines and warning thresholds are yours to set, without asking me for a change.

You attach them to the case — the CIOMS form, the original email, the clinical report — and say what each one is as you upload it. You can also list the cases that have no source documents.

Files are stored encrypted, checked against silent corruption, and opening one is itself recorded.

A compliance report per period and per client lists what was on time, what was late and what is pending. Per case, the single PDF below carries the whole state history — when it entered each stage and who moved it on.

A single PDF per case with the data, the state history and the audit trail together. Any listing, carrying a header with who produced it, when, the filters and an export identifier. That identifier sits in the audit trail, so the file in their hands ties back to the moment it was generated.

Plus the user access listing — role, organisations, last access — which is what they ask for when they check your periodic access review.

Five, and the boundaries between them are the point — separation of duties is one of the first things an auditor checks:

• Data entry — creates and edits draft cases.
• Reviewer — reviews, approves, or returns a case with comments.
• PV responsible / QPPV — locks and unlocks with a reason, sets the timelines, sees the metrics.
• Auditor — read-only over cases and the full audit trail, with export. This is the login your client's auditor gets.
• Administrator — manages users and configuration, and cannot edit case data.

And no role — the administrator included — can modify the audit trail.

Permissions go by role, so someone entering cases cannot approve one. Approval asks for the password again and records the signatory, the time and what the signature meant. Each signature is tied to the exact content that was signed: if the record is altered afterwards, the system shows that the signature no longer matches.

No — and be careful with any vendor who claims theirs is. Validation is demonstrated for one specific installation, with your users and your procedures. A claim made about the product in general glosses over the part that lands on your desk.

What Vigila does is produce the evidence as it is built: every requirement has a permanent identifier, every test names the requirement it proves, and the traceability matrix comes out of the system itself — not written by hand afterwards.

The documentation written and sent to you to review, approve and sign — and brought up to date whenever the system changes. Help drafting your own validation procedure and the procedures that cover the use of the system. The answers when a client audits me as your supplier. And the evidence itself when an auditor asks for it.

It is validation of the system, not regulatory advice: your case assessments, your submissions and your pharmacovigilance procedures stay yours.

It is in the monthly fee. No ticket, no hourly invoice.

I configure the system, migrate your data, write the documentation and keep it current.

Yours is the part nobody can do for you: approving the requirements, signing the documents that carry your name, and running the acceptance testing with your own people. A supplier who offers to sign your procedures instead is handing you a finding at your next inspection.

Yes — it is what Vigila was designed for, not an option bolted on. Separation is built into the database itself, so a user assigned to one client cannot reach another's cases by any route, including editing an identifier in the address bar.

In the European Union, only. Adverse event data is special-category health data and is treated that way: encrypted in transit and at rest, encrypted attachments, no personal data in technical logs, a data-processing agreement, no transfer outside the EU.

A full copy every day and a further copy every four hours, stored encrypted and away from the main system. At most four hours of data at risk, and back in service within eight hours.

Backups are regularly restored into a separate test environment, and the result is reported automatically — a backup nobody has ever restored is a claim, not a control.

You leave. The monthly plan has no minimum term — one month's notice, whenever you want. You take everything — cases, attachments and the full history — in an open format, per client. Built in rather than negotiated, because being able to leave is what makes staying a decision.

Consultancies and CROs that manage cases for marketing-authorisation holders, and holders that manage their own. The only difference is the number of clients: a client is one holder, so a consultancy serving five holders has five, and a company with only its own products has one.

Both. You code reactions against MedDRA, and Vigila builds the E2B(R3) file for you to upload — checked against the conformance rules before you get it, so a missing element turns up here rather than in a rejection notice. What it does not do is transmit: the file leaves through a person, which at these volumes is what the EMA expects anyway.

You license MedDRA yourself, directly from the MSSO.

For the volumes Vigila is priced for — up to 1.000 cases a year per client — no. Exporting the XML and uploading it through EVWEB or EVPOST is what the EMA itself expects from small and medium organisations, and skipping the gateway removes the most expensive piece of the usual project.

No. Vigila covers medicines for human use only.

Launch is estimated for September 2026. If your own deadline is earlier or later — a contract, an audit, a client start date — tell me and you get a straight answer against it.