Status: DRAFT — not a legal document until reviewed and issued by qualified counsel. This exists to give a lawyer a running start, not to replace one. Placeholders in
[BRACKETS]need real values (governing law, notice address, signature block, etc.) before this goes anywhere near a client.
This Agreement ("Agreement") is entered into between Drugvigil ("Provider") and [CLIENT COMPANY NAME] ("Client"), collectively the "Parties", effective as of the date of the Client's initial admin account activation within the Drugvigil MedDRA Coding Toolkit (the "Tool").
1.1. Each Party may disclose to the other non-public information, including but not limited to: Client's MedDRA API credentials and subscription details, Client's internal pharmacovigilance processes, Provider's Tool architecture and security practices, and the terms of this Agreement ("Confidential Information").
1.2. Each Party agrees to: (a) use the other's Confidential Information solely to perform under this Agreement; (b) protect it with at least the same care it uses for its own confidential information, and no less than reasonable care; (c) not disclose it to any third party without prior written consent, except to employees/contractors with a genuine need to know, bound by equivalent confidentiality obligations.
1.3. Confidential Information does not include information that: is or becomes public without breach of this Agreement; was already known prior to disclosure; is independently developed without reference to the other Party's Confidential Information; or is rightfully received from a third party without confidentiality restriction.
1.4. These confidentiality obligations survive termination of this Agreement for [X years / indefinitely for API credentials & trade secrets].
2.1. Client represents and warrants that it holds, and will maintain for the duration of use, a valid and active MedDRA subscription/license issued directly by the MSSO.
2.2. Provider is not a party to, and has no visibility into or responsibility for, Client's relationship, subscription terms, or standing with the MSSO. The Tool provides a coding/training interface only — it does not grant, extend, or substitute for a MedDRA license.
2.3. If Client's MedDRA subscription lapses, is suspended, or is revoked, Client is solely responsible for the consequences, including any resulting inability to use MedDRA-dependent features of the Tool.
3.1. Client shall use the Tool solely for internal, authorized-personnel training and coding-support purposes.
3.2. Client shall not: make the Tool or any MedDRA data accessed through it available to the public; resell, sublicense, or redistribute access to any third party outside Client's own organization; or use the Tool in a manner that violates MSSO's own terms governing MedDRA use.
4.1. Client's MedDRA API key is encrypted at rest and in transit within the Tool. Provider maintains no standing operational access to decrypt, view, or otherwise use Client's API key or MedDRA subscription/account details.
4.1.1. Encryption at rest. Client's MedDRA API key/customer ID, SMTP credentials
(if configured), and each user's two-factor authentication seed are encrypted using
Fernet symmetric encryption (AES-128 in CBC mode with a PKCS7 padding scheme, and a
SHA-256-based HMAC for authenticity/integrity, per the cryptography library's Fernet
specification). The encryption key itself is never stored in the database — it lives
only in a server-side environment variable or a locally-generated key file — so a
database export or backup alone does not expose Client's credentials. Encryption in
transit is provided by TLS on the connection between Client's browser and the Tool
(configuration of TLS/HTTPS at the hosting/infrastructure layer is Provider's
responsibility as operator of the Tool).
4.2. Client is solely responsible for the confidentiality of its API key on its own end (credential hygiene, limiting personnel access, secure storage of any local copies).
4.3. Suspected compromise. If Client suspects its API key has been compromised or exposed, Client shall, without undue delay: (a) rotate/regenerate the API key directly with the MSSO/MedDRA issuer; and (b) notify Provider at [SECURITY CONTACT EMAIL] within [24 / 48] hours of becoming aware, so Provider can revoke and reissue the stored key within the Tool for Client's tenant.
4.4. Provider will notify Client promptly if Provider becomes aware of any actual or suspected unauthorized access to Provider's systems that could affect Client's stored (encrypted) key.
5.1. Provider does not access, process, host, or store Client's underlying pharmacovigilance case data, adverse event records, or patient-level information. The Tool operates over Client's own MedDRA access for coding practice and reference purposes only.
5.2. Data ownership, privacy compliance (e.g., GDPR, HIPAA, or other applicable regimes), and case-data governance remain fully and solely Client's responsibility.
5.3. Provider's audit logging (see Tool documentation) records account activity — logins, role changes, admin actions — for Client's own compliance and security purposes (21 CFR Part 11 traceability), not case-level PV data.
5.4. 21 CFR Part 11 controls implemented in the Tool. The following technical controls are built into the Tool in support of Client's own Part 11 compliance program (this is not a representation that the Tool is independently Part 11 "certified" — no such certification exists; Client's qualified personnel remain responsible for validating the Tool's fitness within Client's own compliance program):
(a) §11.10(e) — Audit trails. Every account/admin action (logins, role changes, password resets, credential changes, GDPR erasures, etc.) is written to an append-only audit log with timestamp, acting user, role, tenant, source IP, and outcome. The audit log and the per-user agreement-acceptance record are enforced append-only at the database layer itself (write-blocking triggers reject any UPDATE or DELETE), not merely by application-code convention.
(b) §11.10(d)/(g) — Limiting system access to authorized individuals. Role-based access control (platform operator / tenant admin / coder / trainee, each scoped to only the data and actions their role permits), unique per-user login credentials, a configurable password policy (minimum length/complexity, expiration, reuse history, account lockout after repeated failed attempts), and optional/enforceable two-factor authentication (TOTP or email one-time code).
(c) §11.200 — Signature manifestation for critical actions. Where enabled, an admin performing a designated critical action (e.g. GDPR data erasure, a forced password reset) must re-enter their own password and record a stated meaning-of-signature before the action executes; both successful and failed attempts are written to the signature log.
(d) §11.10(c) — Record retention/availability. Audit and signature records are retained independently of the user accounts they describe (a user's own account being erased under GDPR does not remove their historical audit/signature entries).
6.1. Subject to payment of applicable fees, Provider grants Client a non-exclusive, non-transferable, revocable license to access the Tool for the number of seats specified in the applicable Order Form.
6.2. License model: per-seat, per-tenant, term-based (see Order Form for seat count, price per seat, and term length).
6.3. Payment terms: [NET 30 / annual upfront / per Order Form]. Non-payment past [X days] entitles Provider to suspend Client's seats (consistent with the Tool's built-in billing-expiry/seat-suspension mechanism) until payment is resolved.
6.4. Renewal, upgrade/downgrade of seat count, and termination terms per [Order Form / Section X].
7.1. The Tool is provided "as is" for coding training/support purposes. Provider makes no warranty regarding the accuracy of any specific MedDRA term suggestion as a substitute for Client's own qualified coding review.
7.2. [Standard mutual limitation-of-liability and indemnity clauses — insert counsel-approved language here; do not use boilerplate without legal review given potential PV/regulatory context.]
8.1. This Agreement remains in effect for the duration of the Order Form term, and renews per Section 6.4.
8.2. Either Party may terminate for material breach not cured within [X days] of written notice.
8.3. Upon termination, Provider will disable Client's tenant access and purge the Client's encrypted API key from active systems within [X days], retaining only what is required for legal/audit retention obligations.
9.1. Governing law: [JURISDICTION].
9.2. Notices to Provider: [ADDRESS/EMAIL]. Notices to Client: per the admin contact on file in the Tool's tenant record.
| Drugvigil (MedDRA Learner) | [Client Company Name] |
|---|---|
| By: _____________________ | By: _____________________ |
| Date: _____________________ | Date: _____________________ |
At the moment the Client's first admin account is activated (/invite/{token} accept
flow), the Tool should present a clickwrap checkbox referencing this Agreement's
version number, and log the acceptance (user, timestamp, IP, agreement version) in the
audit trail — this is evidence that the accepting individual saw and agreed to the
terms, it does not replace the signed Agreement above. Ask to have this built once the
Agreement text is finalized by counsel, since the checkbox should quote/link the
final, lawyer-approved version — not this draft.