Last updated: 10 September 2026

Version: 2026-09-10_v6 (supersedes 2026-08-31_v5; re-acceptance required) Effective: 10 September 2026 Provider: DJG Media Limited (trading as Brigid), CRO No. 762838, Coliemore House, Coliemore Road, Dalkey, Dublin, Ireland Governing law: the laws of Ireland; exclusive jurisdiction of the Irish courts

1. Services

DJG Media Limited (trading as Brigid), CRO No. 762838 ("we") provides Brigid, a multi-tenant practice administration and clinical-record system for medical practices (the "Service"). The Service is accessed via a web browser and includes:

Patient Management: Comprehensive patient demographic and clinical data management.
Appointment Scheduling: staff-controlled diary and booking tools.
Brigid administrative assistance: the enabled administrative routes described in clause 5 and other non-clinical administration; no diagnosis, medical advice or clinical drafting.
EU speech-to-text dictation: raw text for clinician review where enabled.
Communications: staff-controlled email or SMS only where the provider route and clinic purpose are approved; Generative outreach and voice calling are disabled for launch.
Billing & Payments: Subscription management and payment processing via Stripe.

2. Use Rights & Restrictions

We grant you a non-exclusive, non-transferable licence to access and use the Service for your internal business operations. You agree not to:

Resell, sublicence, or lease the Service to third parties.
Reverse-engineer or attempt to discover the source code of the Service.
Modify or create derivative works based on the Service.

You must comply with the Acceptable Use Policy at askbrigid.com/acceptable-use, which forms part of these terms. We may suspend or terminate access as that policy describes.

3. Service Levels

Any binding availability target, support window, maintenance notice, service credit and exclusion is stated in the signed order form or service-level schedule. This public page does not promise a numerical uptime level that has not been backed by production evidence.

4. Data Ownership & IP

Customer Data: You own all right, title, and interest in and to all data submitted by you or your users to the Service.

Company and Brigid IP: We own the platform, software, Brigid orchestration/configuration, brand assets, and documentation. Third-party models and services remain the property of their providers. No rights are granted except for the limited licence to use the Service.

5. Brigid AI Features — Patient Permissions, Clinician Duties, EU AI Act

Brigid's Google Generative AI boundary is administrative operations and non-clinical research with source links only. It must not diagnose, triage, recommend treatment, prescribe, interpret a patient's condition, generate a clinical record, or replace professional judgement. Existing unclassified and clinical model routes are disabled for launch. The provider route is Google Vertex AI (EU); Google AI Studio and US/global fallback routes are disabled.

Patient permissions and clinic instructions remain relevant to processing that is otherwise lawful and contractually permitted. They do not authorise a prohibited provider purpose, and the patient-facing Generative AI surface is disabled for launch.

Enabled administrative routes: the following administrative routes were enabled between 25 and 31 August 2026 and run on Google Vertex AI (EU): (a) a pre-consultation factual chart summary, restating information already recorded in the patient's chart for the treating clinician; (b) administrative mailbox triage — labelling and one-line summaries of the practice's own correspondence, with reply drafts limited to logistics; (c) emailed-document filing — identifying which patient an emailed document belongs to and filing it, without interpreting the document clinically; and (d) an onboarding setup assistant used during clinic setup. Every output of these routes is shown to staff as AI-generated and is subject to human review before it is relied on. None of them produces a diagnosis, triage, risk grading, treatment recommendation or clinical note.
Separate processing: raw clinical transcription uses Google Cloud Speech-to-Text on an EEA endpoint. Research export requires its own lawful basis, minimisation and controller instruction; it is not enabled by a general AI permission.

Customer Clinicians acknowledge that:

They will only initiate Brigid actions whose purpose is permitted, enabled for their clinic and authorised by their role and the applicable patient/controller controls.
They will not attempt to circumvent the permission gates (e.g. by recording outside the Service when a patient has voice transcripts disabled).
They retain professional responsibility for every clinical decision and document signed in the Service, regardless of Brigid's involvement.

The launch intended purpose is practice administration, not diagnosis, treatment, triage, prescribing or clinical decision support. The formal medical-device and AI Act classification record remains a launch approval item; these terms do not replace that assessment. Customers must provide applicable transparency and must not use Brigid for an excluded clinical purpose.

6. Audit and logging

The Service records security, access and consequential-action events to an append-only audit log. The database refuses updates, deletions and truncation of those records, and each audit row carries a hash of the row before it, so a removal or an alteration is detectable rather than silent. This is not a representation that every database event is captured; the categories captured are listed in the clinic release evidence. Retention follows the approved record-category schedule, the controller's documented instructions, necessity review, and applicable legal or professional requirements.

On request and with appropriate authority, audit-log extracts are made available to the data controller (your clinic), the Data Protection Commission, the Health Information and Quality Authority, and the Clinician's professional regulator.

Patient access-log extracts (Article 15). The Service can produce a patient's own access log: the date and time of each access, the name and role of the person who made it, what was accessed, the stated reason, whether emergency break-glass access was used, and the categories of data involved. It is produced from within the practice by a member of staff who holds permission to view that patient and a care relationship with them. It never includes a staff member's IP address, device or user agent, which describe the staff member rather than the patient. Producing an extract is itself recorded in the log, so it appears in the next one. Patients exercise their Article 15 rights through their clinic, which is the controller of their records: this clause is our commitment that the Service gives the clinic the means to answer such a request, not an undertaking by us to answer it to the patient directly.

7. Limitation of Liability

Liability is governed by the signed order form and applicable mandatory law. Nothing in these terms excludes or limits liability that cannot lawfully be excluded, including for fraud, fraudulent misrepresentation, or death or personal injury caused by negligence. Any negotiated cap, data-protection allocation, indemnity and insurance requirement must be stated in the executed clinic agreement; this public summary does not replace it.

8. Governing Law

This Agreement and any disputes arising out of it will be governed by the laws of Ireland, including the Irish Companies Act 2014 and Sale of Goods and Supply of Services Act 1980. The parties agree to the exclusive jurisdiction of the Irish courts.

The Service is provided by DJG Media Limited (trading as Brigid), CRO No. 762838, registered office at Coliemore House, Coliemore Road, Dalkey, Dublin, Ireland. The Brigid family comprises Brigid for staff and clinics and Brigid Patient for patients; voice dictation is built into Brigid. Brigid is the AI assistant embedded in those services. These are product names, not separate legal entities. Agreements previously titled the MedPro AI Terms of Service are this same agreement, now titled Brigid Terms of Service.

9. Term, suspension and termination

Termination rights and notice or cure periods are those in the executed order form. Following termination, we make customer data available for export and then return or delete it in accordance with the executed DPA, the controller's documented choice, and applicable law. The signed order form or DPA must state the export window, active-system deletion deadline, and verified backup-expiry process before production patient data is accepted; no default public period is represented as approved. Tax and accounting records that DJG Media Limited holds for its own legal obligations are retained for the applicable period (generally six years under Irish Revenue guidance).

Suspension or termination for breach of the Acceptable Use Policy is as that policy describes (clause 2).

10. Professional-use obligations (Schedule 1)

The professional-use obligations published at askbrigid.com/clinician-terms — registration, indemnity, clinical authorship, audit-log accuracy, patient privacy and notification of regulatory change — form a schedule to these terms and are set out in Schedule 1. Schedule 1 forms part of these terms and binds every clinician who uses the Service for clinical work. The published page is provided for information; if it and Schedule 1 differ, Schedule 1 applies.

Schedule 1 — Professional-use obligations

This Schedule applies to every licensed clinician (medical doctor, dentist, nurse, physiotherapist, pharmacist or allied health professional) who uses the Service for clinical work (the "Clinician"), on any clinician-facing surface. If the Clinician does not accept these obligations, the Clinician must not use the Service for clinical purposes.

Registration. The Clinician will keep their registration with the relevant professional body current: the Medical Council, the Dental Council, NMBI, CORU, the Pharmaceutical Society of Ireland, or the statutory regulator for the profession.
Professional indemnity. The Clinician will maintain professional indemnity insurance covering their clinical scope of practice for the whole period of their use of the Service.
Notification of regulatory change. The Clinician will notify DJG Media Limited within 30 days if their registration or their indemnity insurance changes status, including suspension, restriction, expiry or lapse.
Clinical authorship and verification. As part of their professional record-keeping duty and under these terms, the Clinician must author, read, verify and correct the clinical record before it is signed, sent, filed or acted on. The Clinician must not attempt to bypass the disabled clinical-AI boundary, and must not use an administrative or non-clinical feature for diagnosis, triage, prescribing, treatment or medical advice.
Audit-log accuracy. The Clinician will not falsify, delete or attempt to circumvent the audit log of their clinical actions. This is a contractual security and accountability requirement and supports the Clinician's professional record-keeping duties.
Patient privacy. The Clinician will access only the patient records strictly necessary for the care they are providing, applying the least-privilege principle and the data-minimisation principle in Article 5 of the GDPR.

Brigid Terms of Service — provenance

This note is not part of the contract. It is rendered on askbrigid.com/terms beneath the SHA-256 footer, and it is deliberately kept out of the fingerprinted bytes: a hash over a contract should cover the contract, not a commentary on it. The canonical contract file is docs/legal/CLINICIAN_TOS_2026-09-10_v6.md, and the SHA-256 shown on the page is the SHA-256 of that file, whole and unmodified — the same value stored on the terms_versions row that every acceptance binds to. Anyone can recompute it.

Why the fingerprint exists

Version 2026-07-21_v4 did not have one. Six accounts accepted that version, and our own record could say only that they accepted something with that label — not what it said. This is the same defect the 2026-08-31 Article 28 review found in a vendor's DPA, and it is not fixed retrospectively: no fingerprint has been asserted for v4, because whatever is published today may not be what those six saw, and a hash claimed after the fact turns an unknown into a false claim. v4 remains evidenced by the published page alone.

Established 18 September 2026: v4 is one label over more than one text

The decision above was taken as a matter of prudence — whatever is published today may not be what those six saw. It is now evidenced, and the position is worse than prudence assumed.

The six v4 acceptances are dated 21 July (1), 26 July (1), 30 July (2), 1 August (1) and 8 August (1). On 24 July 2026, commit 8bae57930f ("feat(brand): apply Brigid naming and artwork to the marketing site") changed the operative wording of the published terms page — marketing/src/app/terms/page.tsx, 19 insertions, 14 deletions. Among the changes, in the body of the contract rather than its styling:

-  MedPro AI provides a multi-tenant, AI-powered clinical workflow automation platform for
-  medical practices (the "Service").
+  {ORG.legalName} provides {ORG.staffProductName}, a multi-tenant, AI-powered clinical
+  workflow automation platform for medical practices (the "Service").

The name of the party providing the Service changed inside the contract text. One account accepted before that change and five accepted after. Eleven further commits touched the page between 21 July and 31 August, including 35bf8b6aa8 ("feat(legal): reclassify Ask Brigid as admin-only, off the Class IIa MDR path") on 14 August — after the last v4 acceptance, so outside the window, but it shows the page was under active legal revision throughout.

What follows from this.

No single text can be attached to the v4 row without misrepresenting at least one of the six acceptances. The earlier reasoning — that a hash claimed after the fact turns an unknown into a false claim — holds, and now has a specific counter-example behind it rather than a general caution.
A version label is not an identifier of what was agreed. It was treated as one until 2026-08-31. The fingerprint exists because of that, and this is the concrete harm it prevents.
The one acceptance of 21 July agreed to terms naming a different provider. Whether that matters is a question for counsel, not for this note. It is recorded here so that it is a known fact rather than a discovery.

Not remediated, deliberately. The content column on that row stays null. Filling it with any recovered page text would assert that all six saw that text, which is now demonstrably false for at least one of them. terms_versions carries the label, the date and the acceptances; what each person saw is reconstructible only from the git history of the published page, and this note is the pointer to it.

Who is still exposed, checked 18 September 2026. The six acceptances come from five distinct accounts (one accepted twice). Of those five:

| | Accounts | |---|---| | Have since accepted a fingerprinted version (v5 or v6) | 2 | | Have only ever accepted v4 | 3 |

So three live clinician accounts are bound to a version whose text cannot be produced, and whose label covers at least two different texts. That is the exposure, stated as a number rather than as a caution.

The honest remedy is forward-looking, and it is small: ask those three to accept the current version, which carries a fingerprint. That replaces an unprovable acceptance with a provable one. It does not repair the historical record — nothing can — but it means no account is currently bound to text nobody can produce. Retrofitting a hash to the v4 row is still refused, for the reason above.

Version history

2026-08-31_v5 — the first version with a canonical file and a fingerprint. Its wording was EXTRACTED from the page that was already publishing it — not retyped — and the extraction was diffed back against that page's own text before the file was created: 771 words each side, identical. No clause was added, removed or reworded in v5. Two accounts accepted it, and those acceptances remain bound to the v5 fingerprint (abb3406a692e18314223f2ce63b909314fa68e4d9eb44b317f5f519d9b80025c), not to anything published later.

2026-09-10_v6 — changes the wording, so it is a new terms_versions row with its own fingerprint and every account is asked to accept it afresh. What changed:

this provenance note was moved OUT of the contract text, so the hash covers the contract alone;
the Acceptable Use Policy was incorporated into clause 2;
the "administrative candidate" wording in clause 5 was replaced with the four administrative routes actually enabled between 25 and 31 August 2026 on Google Vertex AI (EU);
a single entity and governing-law form was adopted, matching the DPA;
clause 6, "Audit and logging", is new. It states the append-only guarantee and the hash chain, and it puts the patient access-log extract back into the contract. That sentence had been removed on 7 September 2026 because the extract did not exist and the terms should not promise what the product could not do. It exists now — patient_access_log_extract, a tenant-scoped, permission-gated, care-relationship-gated function that returns no staff IP or user agent and records its own use — so the commitment is made again, in the accepted document rather than only on an informational page;
clause 9 (term, suspension and termination) carries the house post-termination data sentence;
clause 10 and Schedule 1 bring the professional-use obligations, previously published only on the unfingerprinted /clinician-terms page, into the accepted document.

Questions? Email legal@askbrigid.com

Download compliance documents

Privacy Policy Data Processing Agreement Sub-Processors Terms of Service MyBrigid Terms Clinician Terms Cookie Policy Acceptable Use Accessibility Software qualification

Brigid Terms of Service