Published update — not yet the in-app acceptance version. This edition awaits legal review and activation. Existing acceptance records retain their original wording. Read the version currently linked from the app.

Version: 2026-09-28_v7 Publication date: 28 September 2026 Application: This updated edition is published for review. It is not yet the version offered for in-app acceptance. It does not replace an existing agreement merely by publication. Provider: DJG Media Limited (trading as askbrigid.com and myBrigid), 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 askbrigid.com and myBrigid), CRO No. 762838 ("we") provides Brigid, a practice administration and patient-record platform (the "Service"), through its clinic web and iOS apps and the connected MyBrigid patient app. The executed order identifies the Customer, plan, enabled features and processing instructions.

The Service includes patient-record management, staff-controlled scheduling, clinic communications, document handling and billing. Optional AI assistance, transcription and patient conversations are subject to clause 5 and the clinic's approved feature and supplier schedules. A plan name or a permission setting does not authorise a feature that is unavailable or has not completed its required review.

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

The intended AI functions are transcription, preparation of draft notes from supplied material, factual summaries of existing records, administrative patient conversations and assistance with clinic email. Brigid is not intended to make diagnoses, grade medical risk, perform clinical triage, recommend treatment, prescribe or make autonomous clinical decisions. The actual intended purpose, outputs and use of each feature must be assessed; describing it as administrative does not determine its medical-device status or override supplier terms.

Only functions identified as approved and enabled in the Customer's release schedule are included. Before enabling a function, the Supplier must verify the applicable provider agreement, processing route, privacy assessment and regulatory position. No patient choice or Customer instruction overrides an unlawful or contractually prohibited use.

• Patient notes and dictation: staff must identify the patient and verify their record access and the patient's applicable AI permission before sending patient content to AI or cloud transcription. Automated checks must support this requirement; the current implementation status is disclosed in section 6 of the Privacy Policy. The same rule applies when the clinician dictates their own note about the patient. A consultation recording also requires the clinic's recording procedure, notice and applicable permission.
• General notes: staff may record an administrative note after confirming that it contains no patient information. General note is not a way to bypass a patient's refusal or a missing record link. Staff use the patient-note flow if patient information is involved.
• Chat and summaries: patient-linked inputs, retrieved records and reusable conversation material require the applicable access and permission checks. Historical conversation material whose patient scope cannot be verified must be excluded from new AI input while remaining available for authorised staff viewing. The rollout of the automated exclusion is disclosed in section 6 of the Privacy Policy. The service must not represent an unverified patient scope as consented.
• Patient conversations: where approved and enabled, these cover administration such as appointments, clinic information and payments. They do not replace advice from a healthcare professional. Messages requiring clinical judgment are directed to the clinic through its care process.
• Clinic email and attachments: authorised staff can connect approved clinic/shared or individual staff mailboxes and use the enabled email assistance. The Customer must have authority for the mailbox and the processing, document the purpose and lawful basis, and comply with transparency and applicable confidentiality duties. The supplier schedule must cover the actual email and AI providers. Email processing is not represented as automatically checking a patient-specific consent for every unlinked message or attachment.
• Review: staff check AI output against its source, correct errors and omissions, and approve a draft before signing, sending, filing or relying on it. An AI draft is not an autonomous clinical decision.

Clinicians remain responsible for professional judgments and the records they approve. They must use only functions permitted for their role and purpose, and must not circumvent access, patient-choice or recording controls. The medical-device and AI Act assessment is recorded separately against the actual release; these terms do not assert that an assessment or regulatory approval has been completed.

6. Audit and logging

The Service maintains audit records for covered security, access and consequential-action events. The clinic release evidence identifies the events captured, the applicable integrity and access controls, and material limitations. This is not a representation that every database event is captured or that every log has identical immutability or external anchoring. 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 askbrigid.com and myBrigid), CRO No. 762838, registered office at Coliemore House, Coliemore Road, Dalkey, Dublin, Ireland. The Brigid family comprises Brigid for staff and clinics and MyBrigid 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.

1. 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.

2. 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.

3. 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.

4. 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 bypass the approved feature, access or patient-permission controls, and must not use an administrative feature for diagnosis, triage, prescribing, treatment recommendations or medical advice.

5. 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.

6. 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.

Related legal documents

Clinician Terms of Service · MyBrigid Terms of Service · Privacy Policy · Data Processing Agreement · Software qualification statement · Acceptable Use Policy · Cookie Policy · Compliance Overview

---

Download the exact document (Markdown)

SHA-256: c510e1d07972e97c7a12b8c80afca1fd292d4fcea48acfa203d6c28389ba2e77
Source: docs/legal/CLINICIAN_TOS_2026-09-28_v7.md

---

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.

1. 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.
2. 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.
3. 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:

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.