Built so the audit is the easy part.

No. A template builds the narrative from the structured data you already entered, and you edit it from there. Edits are audited like any other field, so an earlier wording can be recovered. Drafts save themselves, and a case can be copied into a new one.

The system holds each product's listed terms with an effective date and country. Expectedness is derived against the list in force on the date of the reaction, not the one in force today — the distinction an assessor challenges.

You can override it. The override needs a reason, and the derived value is kept beside 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 underneath you. No last-writer-wins, no silent overwrite — a quietly lost edit is the kind of thing you only discover during an audit.

The workflow is configuration: stages, who may move a case between them, a separate route per case type. Reporting thresholds and traffic-light limits are yours to set, without waiting for a release.

CIOMS forms, the original email, clinical reports — attached and classified on upload, so you can list the cases with no source document instead of finding out during the audit. Encrypted, hashed, 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, a tracking view shows when it entered each stage, how long it stayed, 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 — and 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.

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. The signature is bound to the signed content by a cryptographic hash: alter the record afterwards and verification fails.

No — and be careful with any vendor who says their product arrives that way. Validation is demonstrated for one 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: requirements with permanent identifiers, tests tagged with those identifiers, and a traceability matrix generated from the code itself.

The documentation written and sent to you to review, approve and sign — and rewritten when a change dates it. Help drafting your own validation procedure. And the evidence itself when an auditor asks for it.

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

Configuration, migration, documentation and upkeep are mine. Yours is what only you can do: approving the requirements, signing what you sign, and running the acceptance testing with your own people. A supplier who offers to sign your procedures for you is selling you a future finding.

Yes — it is the case Vigila was designed for, not an option bolted on. Separation is enforced in the data layer, 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-reaction 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 processing agreement, no transfer outside the EU.

A full backup daily, an incremental every four hours, stored encrypted away from production. At most four hours of data at risk, and back in service within eight.

Backups are restored on a schedule into a throwaway environment and the result reported automatically — a backup nobody has restored is a claim, not a control.

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.

The data is E2B(R3)-structured from the first record and coded fields already carry the dictionary and its version, so MedDRA coding and XML generation arrive later without touching your data. They are not in the first release, which closes the gap that actually hurts: a proper register with a proper history.

A MedDRA subscription, when you need one, is licensed by you from the MSSO and is not resold here.

At these volumes, no. Exporting the XML and uploading it through EVWEB or EVPOST is what the EMA expects from small and medium organisations, and it removes the most expensive piece of the usual project.

The first release is pharmacovigilance. The structure is not hostile to the others, but claiming them today would be the overclaim this page is trying to be the opposite of.

Vigila is in development and no public date is promised here: a date on a website is a commitment made before knowing your situation. Send me your own deadline — a contract, an audit, a client start date — and you get a straight answer against it.