A User-Centric Electronic Health Record + AI for Caribbean Clinics

Terms of Service

Effective date: 01/07/2026

MedRegis — Legal Document Completion Checklist

Start here: MedRegis_Legal_Session_Handoff.md carries the full context, reasoning, and audit trail behind this checklist’s current state — read it first when resuming this work in a new session. Update the handoff whenever this checklist or the Founder’s Notes change.

Terms of Service, Privacy Policy, Data Processing Addendum • updated after finalising document content

The red-bracket content in all three documents is now filled — hosting, sub-processors, security measures, retention, DPO contact, and addresses are all in. Across the three contract documents the only literal blank left is the effective date; the Incident Response Procedure adds its own blank (its “Last reviewed” date), to be filled on adoption. What remains below is diligence, enforceability, and compliance work that sits outside the document text. Completed items are shown ticked for reference.

A. Before publishing

☐ Adopt the MedRegis Incident Response Procedure. Drafted (v1.0 DRAFT). To adopt: remove the DRAFT marking; set the “Last reviewed” date and version it; name the written delegate for the Incident Lead (CEO is named, delegate is not); and close the reviewer’s-note points.

PUBLISHING BLOCKER — downgraded, not cleared. DPA Schedule 2 states that MedRegis maintains incident response procedures. A draft “for review,” with no delegate and open reviewer points, is not a “maintained” procedure, so Schedule 2’s incident-response line stays the one outstanding false statement in the set until adoption. Adoption cures it: the draft already covers every element Schedule 2 asserts (identify, escalate, investigate, respond, notify per clause 8).

Reviewer’s three points are already tracked, not new work: the delegate is inside this item; the per-Subscriber security contact and the log-retention window are the two Section C items that already name this procedure. Only “name the delegate” is genuinely new.

Procedure-side cleanups to make on adoption (internal document, so none is a contract error — but catch them once): (i) Section 6 attributes the 10-working-day record deadline to clause 8.4 — 8.4 requires the record, not the timing; the 10 days is our internal standard, so reword to say so. (ii) Section 7’s blanket “MedRegis remains responsible… under clause 6.2” should acknowledge the 6.7 carve-out — for the data Twilio holds as independent controller, a Twilio-side breach is Twilio’s own notification obligation, not MedRegis’s. (iii) Section 7’s sub-processor list omits Meta/WhatsApp — add it. (iv) The role name “Subscriber Contact” collides with the Subscriber’s own designated contact under Terms 3.5 — rename to “Subscriber Liaison” to avoid ambiguity in a real incident.

☐ Have a Barbados-qualified attorney review and sign off on all three documents.

Non-negotiable given health data. Add local-law review for non-Barbados clinics.

☐ Counsel: confirm the 12-month liability cap (Terms 15.1) reaches the new money obligations in DPA 6.4 (refund of unused prepaid fees) and 10.4 (remediation at MedRegis’s expense).

Both sit inside the cap on our reading. Confirm. “Confidential Information” is defined at Terms 2(g), so DPA 10.4 works — no gap there.

☐ Set the effective date and apply it consistently across all three documents (the only remaining blank).

☐ Add a version number and date to each document footer for version control — including the Incident Response Procedure (v1.0 DRAFT), which needs finalising the same way.

☑ Registered address, contact emails, hosting/transfer wording, Schedule 1–3, security measures, retention, and DPO contact — all filled.

B. Provider diligence (behind the sub-processor rows)

☐ Put Anthropic’s and OpenAI’s data processing terms in place (API terms; both no-training by default).

OpenAI business/enterprise terms also offer a BAA option for health data.

☐ Put a data-processing agreement in place with Twilio/SendGrid (Twilio offers a BAA for health data).

Now a listed sub-processor handling patient contact details and message content. ESCALATED: DPA 6.2 now warrants materially equivalent written terms with every sub-processor. An unpapered Twilio is a breach of our own warranty from day one.

☐ Confirm each provider’s retention window for data sent to it; pursue zero-retention/enterprise where available.

☑ Confirmed AI use of the API (not consumer apps), so no model training by default — the key risk point.

C. DPA compliance actions (beyond the documents)

☐ Appoint a DPO (self or team member); record the name internally with an effective date.

Public documents use the role, not the name. Confirm statutory trigger with counsel; consider fractional DPO for large deals.

☐ Confirm registration status with the Data Protection Commission and register if required.

☐ Carry out a DPIA for the EHR processing (including AI features) and keep it on file.

☐ Build a breach-response runbook keyed to the 72-hour clock.

This is the CONTROLLER-role path — Controller Data breaches (account, billing, usage, security/audit-log data), where MedRegis notifies the Commissioner itself under Privacy Policy §11. It is DISTINCT from, and additional to, the Incident Response Procedure, which covers only the processor role (Patient Data breaches, notified to the Subscriber without undue delay under DPA clause 8). Keep the two separate; do not merge the two clocks into one document.

☐ Ensure privacy@ and legal@ forward to a single monitored inbox.

An unwatched security/privacy channel is a breach-response liability.

☐ Confirm with your accountant whether the Barbados record-retention figure is 5 or 7 years (§12 already covers the range).

☐ Capture a security/privacy contact for every Subscriber and hold it in the account record.

DPA clause 8 obliges MedRegis to notify the Subscriber without undue delay. Without an address on file, hour one of a real breach is spent hunting for one. Backstopped, though: Terms 3.5 already obliges the Subscriber to designate a security/privacy contact and deems notice received at the registered contact where none is designated — so this is a speed-and-relationship measure, not a legal exposure. MedRegis has a valid-notice fallback even against a clinic that never designates one.

☐ Confirm the retention window for application, authentication and hosting logs (Heroku, AWS, Cloudflare).

The Incident Response Procedure’s evidence-preservation step assumes the logs still exist. If they age out before a breach is noticed, scope cannot be established.

☐ Perform and time a test restore from backup into a scratch environment.

Not contractual — Schedule 2 deliberately claims no tested restore and no RPO/RTO. Pure operational risk: an untested backup is a hypothesis, and for an EHR an unrecoverable outage is a patient-safety event.

☐ Consider whether a cookie-consent banner is needed operationally (Privacy Policy wording is fine; the mechanism may be needed).

☑ Hosting location confirmed (United States); transfer wording and sub-processor list finalised.

☑ APM tools (Scout, New Relic) confirmed to collect technical data only — no Patient Data.

D. Enforceability — make the terms bind

☐ Implement recorded click-to-accept at signup and at every renewal (checkbox + timestamp + version).

Highest-leverage item outside the documents — this is what makes the strong clauses enforceable.

☐ Retain acceptance logs showing who accepted, when, and which version.

☐ Set the APM agents not to capture request parameters or message bodies (developer hardening task).

☐ Ship the account-settings toggle to disable AI-Assisted Features.

*DPA 12.7 leads with self-service disablement (written request is the fallback). It is also what makes DPA 6.4 near-unbreakable: disablement is always a “reasonable alternative”**, so an objection to Anthropic or OpenAI can never force termination or a refund. Ship it.*

☐ Build the de-identification pipeline to the DPA 3.4 standard BEFORE running any de-identification job.

GATE ON FIRST USE, not on publishing. DPA 3.4 is an undertaking: aggregated or statistical outputs only, irreversible transformation, no re-identification key retained, stored separately from Patient Data. Running a job that does not meet this breaches the contract on day one.

E. Regional / multi-jurisdiction

☐ Map which Subscribers are in which countries (Barbados, Trinidad, Guyana, Jamaica, others).

☐ Meet the statutory obligations that apply to MedRegis in each country, independently of the documents.

The contractual item is closed: DPA clause 14 (Governing Law) no longer promises a local-law schedule and now puts the burden of identifying local requirements on the Subscriber, binding MedRegis only where agreed in writing. The statutory obligations remain and are unaffected by the drafting: Guyana requires a non-established processor to appoint a local representative — act on this if you have Guyanese clinics. Jamaica requires registration and a DPO.

F. Final QA before publishing

☐ Re-verify cross-references (clauses 3, 5, and 9) after any edits.

☐ Confirm the three documents reference each other consistently.

☐ Confirm the Retention Period (60 days) matches in Terms 10.3 and DPA 9.2.

☑ CLOSED. The statute is now “the Act” in all three documents; “DPA” refers only to the Data Processing Addendum. No residual references remain.

G. Parked enhancements — revisit when triggered

Deliberately left out; each tied to a trigger. Full reasoning is in the Founder’s Notes document.

☑ De-identified / aggregated data rights — NO LONGER PARKED. Now in force: DPA 3.3–3.4, Terms 8.1 and 8.6, Privacy Policy §4. See the pipeline gate in section D and the Founder’s Notes.

☐ Shortened limitation period — trigger: next legal review; 6-year Barbados baseline, 2 years mutual if pursued.

☐ SLA / uptime commitment — trigger: a buyer demands one.

☐ IP-infringement indemnity to the Subscriber — trigger: an institutional buyer redlines for it.

☐ Segment.io sub-processor row — trigger: actual implementation.

Note — separate track

These documents govern subscriptions going forward. The current clinic incident runs on the May 2024 terms plus the Computer Misuse Act and confidential-information angles — keep it on its own track: preserve the audit logs and consider the demand letter.

Privacy Policy

Effective date: 01/07/2026

MedRegis — Founder’s Notes: Context, Flags &** Talking Points**

Start here: MedRegis_Legal_Session_Handoff.md carries the full context, reasoning, and audit trail behind these notes’ current state — read it first when resuming this work in a new session. Update the handoff whenever this document or the Legal Completion Checklist change.

Companion to the legal documents and the completion checklist • reasoning and context, not a task list

This document captures the judgement calls, talking points, and things-to-know that came up while finalising the Terms of Service, Privacy Policy, and Data Processing Addendum. The checklist tracks what to do; this explains why, so decisions don’t get relitigated and nothing gets forgotten. Grouped into four buckets: diligence to complete before go-live, talking points if asked, decisions parked for later, and compliance actions beyond the documents.

1. Diligence to complete before go-live

• AI provider terms.** **Put Anthropic’s and OpenAI’s data processing terms in place. You use the API (not the consumer apps), so by default neither trains on your data — that’s the correct footing. Formalise it with each provider’s DPA (OpenAI’s business/enterprise terms also carry the no-training commitment and a BAA option for health data).

• AI retention window.** **Confirm how long Anthropic and OpenAI retain the audio and transcripts you send via API before deletion, and whether a zero-retention or enterprise arrangement is available given this is patient data. You need to know the number and be comfortable with it; it does not go in the documents.

• Twilio / SendGrid terms.** **Twilio (which owns SendGrid) is now a listed sub-processor handling patient contact details and message content for SMS and email. Put a data-processing agreement in place with Twilio (it offers a BAA for health data), the same way as for the AI providers.

• APM hardening.** **Standing instruction for the developer: set the Scout and New Relic agents not to capture request parameters or message bodies. The developer confirmed they currently collect technical data only (no patient data), which is why Schedule 3 lists them as “no Patient Data” — this toggle keeps it that way.

• Acceptance mechanism.** **Implement recorded click-to-accept at signup and at every renewal (checkbox + timestamp + version accepted), and retain the logs. This is what makes the access-control, clinical, AI, and indemnity clauses actually enforceable against a clinic — the single highest-leverage item outside the documents.

• Hosting stays US.** **The country (United States), not the data-centre region, is what the documents commit to — so within-US infrastructure changes need no edit. If you ever configure Heroku or AWS to a non-US region, that flips the transfer analysis and must trigger a document update.

• Google Analytics retention.** **Confirmed at 14 months, matching the Privacy Policy §12 wording. If you change the GA4 setting, update §12 to match.

2. Talking points if asked (nothing to add to documents)

• Physical security.** **Your security wording describes application-level controls, which is what you control and what clinics ask about. Physical and data-centre security is inherited from Heroku and AWS — if a sophisticated buyer or regulator probes it, the accurate answer is “inherited from our SOC 2-compliant hosting providers.”

• Audit logs.** **The audit-log capability is both a genuine security control and a selling point — and it’s the exact capability that made the current-incident analysis possible, since the logs show what any profile accessed. Lead with it when clinics ask about security.

• AI objections have a cheap answer.** **If a clinic objects to Anthropic or OpenAI as a sub-processor, the answer is not a negotiation — it is DPA 12.7: disable AI-Assisted Features. DPA 6.4 says no termination right arises where MedRegis offers a reasonable alternative, and disablement always is one. This is why the disable toggle must ship: it converts the most likely objection a clinic will ever raise into a two-click support ticket instead of a contract dispute with a refund attached.

• Updating Schedule 3 (solved — do not re-solve).** **We can add a sub-processor without re-signing anything. Terms 19 lets MedRegis amend the Terms by posting a new version with notice; Terms 8.2 makes the Data Processing Addendum part of the Terms; DPA 6.3 sets the notice mechanism and 6.4 the objection window. So: publish the updated Schedule 3, give notice, run the 30-day objection clock. DPA 6.6 also means new services, regions, affiliates or successors of an existing sub-processor — and any provider that does not touch Patient Data — need no notice at all.

• Liability cap — the confidentiality hole is closed.** **Terms 15.1 originally carved breach of confidentiality out of the 12-month cap. Patient Data is the Subscriber’s confidential information, so a data breach was effectively uncapped — the cap did not apply to the one event most likely to produce a claim. It is now expressly capped, and the confidentiality carve-out is limited to non-Patient-Data confidential information (source code, designs, know-how). Do not widen that carve-out again.

• Suspension and patient safety.** **Terms 10.1 keeps the right to suspend immediately, but now preserves read-only access to Patient Data for continuity of care where reasonably practicable. Discretion is retained — if the clinic is the threat, we do not have to. But cutting a clinic off from its records mid-consultation is a patient-safety event, and it is the fact pattern a claimant would build a case on. Use the read-only path unless there is a reason not to.

• Spelling convention (deliberate — do not** ****“****fix****”****).**** **“Authorized User” is a defined term from Terms 2(a) and is spelled the US way in all three documents, every time, including in DPA 12.7. Everything else is British — authorised, organisational, licence. That is correct: a defined term is a label and is not re-spelled to suit house style. Checked across all three documents: no instance anywhere uses “Authorised User” as if it were the defined term. Leave it. Re-spelling the term would create the drift that currently does not exist.

• AI data handling.** **When a ministry or clinic asks whether you use their data to train AI, the clean answer is: “We’re on the Anthropic and OpenAI APIs, neither trains on our data by default, both are covered by data processing terms, and here is our retention position.” Being able to say this plainly is a competitive advantage — keep it true.

• No data monetisation.** **SUPERSEDED — do not say this any more. The Privacy Policy no longer gives an unqualified “we don’t use your data” answer, because MedRegis now holds de-identified data rights (DPA 3.3–3.4). We still do not sell data, and we still do not use Patient Data for our own purposes at record level. The accurate line is: “We never sell data. We don’t use identifiable patient data for our own purposes. We do produce aggregated statistics — population-level, irreversibly de-identified, never identifying a patient or a clinic — to improve the Service and report on health trends.” That trade was made deliberately; the aggregate answer is still a strong one, and it is honest.

• Return/deletion design (settled).** **DPA clause 9 restricts processing to secure storage after the 60-day window and then may delete on notice — it does not auto-delete on a timer, and it does not retain indefinitely. This was deliberate: for medical records, premature auto-deletion is a worse risk than short over-retention, and indefinite holding is its own exposure. The wording says “restrict processing to secure storage” rather than “cease processing,” because storage and deletion are themselves processing under the DPA — a promise to stop entirely would be self-contradictory and hard to guarantee. Do not “simplify” this to auto-delete, retain-until-asked, or cease-processing; the middle path is the point.

• Incident Response Procedure is deliberately internal.** **Schedule 2 says MedRegis “maintains procedures” — it does not attach or incorporate them, and it should stay that way. The procedure is not incorporated by reference (unlike the Privacy Policy and the DPA), so it can be revised without running the Terms 19 amendment/re-acceptance mechanism. That is a feature, not an oversight — do not “tidy up” by bolting the runbook into the contract, which would freeze it and turn every operational tweak into a document-change event. Note also that adopting it downgrades the last outstanding false statement in the set (Schedule 2’s incident-response line): a draft “for review” is not a “maintained” procedure, so the item is mitigated-in-progress, not cured, until the DRAFT marking comes off and the delegate is named.

3. Decisions parked for later — revisit when triggered

• De-identified / aggregated data rights.** **NO LONGER PARKED — now settled, with a gate. The right is in force: DPA 3.3 (permitted purposes) and 3.4 (De-identified Data), Terms 8.1 and 8.6, Privacy Policy §4. Two things about 3.4 are deliberate and must not be undone. First, it covers AGGREGATED OR STATISTICAL data only — not record-level data with the identifiers stripped out. Because MedRegis holds the source records, record-level “de-identified” data is arguably still personal data (we always possess the means to re-identify), which would collapse the whole right and mean we had been using patient data for our own purposes with no lawful basis. Aggregation removes the problem: there is no record left to re-identify. Second, 3.4 requires irreversible transformation, no retained re-identification key, and separate storage from Patient Data. THE GATE: these are undertakings about how we WILL do it. Do not run the first de-identification job until the pipeline actually meets that standard, or the contract breaches itself on day one. Do not “simplify” 3.4 back to identifier-stripping — the aggregation constraint is the entire point.

If we ever want more than aggregates.** The constraint is the law, not the contract, and it does not move when we redraft. 3.4 is aggregation-only because MedRegis holds the source records: record-level “de-identified” data, where we retain the original, is pseudonymised, and pseudonymised data is still personal data. Rewriting the clause gives us a wider contractual permission over data that is still legally patient data, used for our own purposes — broader clause, worse exposure. The real question is not “can we redraft 3.4” but “what would have to be true for record-level use to be lawful”. Three routes, ascending in difficulty. Route A — consent:**** the clinic, as controller, obtains patient consent for records to be used in MedRegis’s analytics or model development. This works and is how most health-AI companies do it, but it is the clinic’s job, consent is revocable, withdrawal must be handled, and it is hard to run across dozens of small practices. Route B — genuine anonymisation with separation:**** record-level data can be anonymous if re-identification is not reasonably possible, which means irreversible transformation, no linkage to the source, and a documented re-identification risk assessment (k-anonymity or similar) — in practice a de-identification pipeline run as a distinct system, organisationally separated from production. Doable, expensive, needs expert sign-off. Route C — research provisions:**** data protection regimes on the GDPR model generally carry provisions for scientific research, and a population-health study with a Ministry or a university (AUB or Ross are the obvious partners) is exactly the shape that fits. Confirm with Barbados counsel whether and how the Act provides for this — it is a route to investigate, not a settled position. It carries its own governance: ethics approval, purpose limitation, safeguards. Honest read: training a model on Caribbean clinical data, or building patient-level insight products, is a Route A or C project with a real legal budget, not a DPA amendment — and it would require reworking the Terms and Privacy Policy too, since both now state we do not use Patient Data for our own purposes beyond the narrow carve-out. The thing to avoid is the middle path: quietly widening 3.4’s wording without changing anything underneath. That is the version where the clause looks fine and the practice is unlawful.**** **Trigger: a real analytics, model-training or population-health initiative reaching funding or partnership stage.

• Shortened limitation period.** **The Barbados statutory baseline for a simple contract is 6 years (Limitation of Actions Act, Cap. 231, s.14). A 12-month contractual cut is aggressive, risks being read down against small clinics, can bar your own late-surfacing claims if mutual, and never limits statutory DPA claims. If pursued: use 2 years, mutual, discovery-triggered, with carve-outs for fraud, concealment, unpaid fees, and statutory claims — and confirm with counsel. Low reward; parked.

• SLA / uptime commitment.** **Leave out until a specific buyer demands one; if added, make service credits the sole remedy. Silence protects you more until then.

• IP-infringement indemnity to the Subscriber.** **Hold as a concession you can offer if an institutional buyer redlines for it, not a default.

• Risk-allocation softening.** **The documents are firm-but-defensible (one-way indemnity, fees-based cap, full “as is” disclaimer). Decide per-deal whether to soften for larger clinics; keep the non-negotiable core (data-processing structure, clinical/AI exclusions, access control) separate from the softer terms you can trade.

• Segment.io.** **Add as a sub-processor row (with a dated entry) only when actually implemented — not before.

4. Compliance actions beyond the documents

• Appoint a DPO.** **Designate a Data Protection Officer (yourself or a team member) and record the name internally with an effective date. Public documents use the role, not the name. Confirm the statutory trigger with Barbados counsel; consider an outsourced/fractional DPO for larger institutional deals.

• Registration.** **Confirm your registration status with the Data Protection Commission and register as controller/processor if required.

• DPIA.** **Carry out a Data Protection Impact Assessment for the EHR processing, including the AI features, and keep it on file.

• Breach runbook.** **Build a breach-response runbook keyed to the 72-hour clock (detection, assessment, Commissioner and data-subject notification). This is the CONTROLLER-role path — for Controller Data breaches (account, billing, usage, security/audit-log data), where MedRegis notifies the Commissioner itself under Privacy Policy §11. It is DISTINCT from the Incident Response Procedure, which is the PROCESSOR-role path (Patient Data breaches, notified to the Subscriber without undue delay under DPA clause 8, then the Subscriber notifies the Commissioner). Both are required; keep them as separate documents rather than merging the two clocks, which invites confusion about which applies. Ensure privacy@ / legal@ forward to a monitored inbox — an unwatched channel is a breach-response liability.

• Multi-jurisdiction overlays.** **The contractual item is closed: DPA clause 14 (Governing Law) no longer promises a local-law schedule, and now makes the Subscriber responsible for identifying its own local requirements, which bind MedRegis only where agreed in writing. The statutory obligations are unaffected by that drafting and still apply to MedRegis directly: Guyana requires a non-established processor to appoint a local representative in Guyana — act on this if you have Guyanese clinics. Jamaica requires registration and a DPO. Map clinics by country first. Note also that “Commissioner” in the DPA now means the supervisory authority with jurisdiction over each Subscriber, not only Barbados’s — the documents work regionally, the compliance work still has to be done country by country.

• Record-retention figure.** **Confirm with your accountant whether the applicable Barbados company/tax record-retention period is 5 or 7 years; §12 already covers the range, so no document change is needed either way.

• Cookie consent.** **The Privacy Policy describes cookies and points to browser settings, but there is no consent banner. Consider whether a cookie-consent banner is needed operationally — a wording change is not required, but the mechanism may be.

• “****DPA****”** ****wording (for counsel).**** **CLOSED. The statute is now “the Act” across all three documents, and “DPA” refers only to the Data Processing Addendum. No residual references remain. Nothing further for counsel on this point.

Separate track — the current incident

These documents are forward-looking and do not govern the current clinic incident, which runs on the May 2024 terms plus the Computer Misuse Act and the confidential-information angle. Keep that matter separate: preserve the audit logs showing what the two profiles accessed, and consider the demand letter. Do not let the go-forward document work absorb that live dispute. One incidental benefit from the new drafting: DPA clause 1.2 makes security and audit log data Controller Data, of which MedRegis is the controller. A clinic therefore cannot demand its deletion under clause 9, and the logs can be preserved for the dispute and for our own legal purposes.

5. Change triggers — check the documents before you build

The documents describe a specific product doing specific things. Some roadmap items break that description. Check this list before starting the work, not after shipping it — a change that makes a document false is far more expensive to fix once clinics are live on it.

• BREAKS THE ARCHITECTURE — AI that is not draft documentation.** **DPA 12.1 defines AI-Assisted Features narrowly: third-party AI generating DRAFT CLINICAL DOCUMENTATION from consultation audio or text. Terms 11 and 12 build the entire clinical-liability position on that footing — draft aid only, clinician reviews, MedRegis influences no clinical decision. Clinical decision support, diagnostic prompts, triage, risk scoring, and coding or billing suggestions are NOT draft documentation. They fall outside 12.1, outside the Terms 12 disclaimer, and into territory where MedRegis is shaping a clinical decision. If we pursue decision support (for example an OpenEvidence-style integration), the documents must be reworked BEFORE it ships.

• BREAKS THE ARCHITECTURE — anything where MedRegis decides the purpose.** **Today MedRegis is a processor for everything except Controller Data. That is what holds the whole structure up. A population health dashboard, a chronic-disease registry, or cross-clinic benchmarking where MEDREGIS decides what is analysed and why makes MedRegis a CONTROLLER of patient data: our own lawful basis, our own transparency duty to patients, our own breach duty to the Commissioner. The line: aggregate, irreversibly de-identified statistics are DPA 3.4 and fine. Anything patient-level whose purpose we set is not, and these documents do not cover it.

• Support tooling that can see patient records.** **A helpdesk (Zendesk, Intercom, Freshdesk) whose agents can view Patient Data is a sub-processor: Schedule 3 row, DPA 6.3 notice, 30-day objection window, written terms under 6.2. This is the most commonly missed sub-processor in SaaS.

• Integrations that move Patient Data outward.** **Lab, pharmacy, referral and clearinghouse integrations either create new sub-processors or send Patient Data to ANOTHER CONTROLLER. The DPA is currently silent on controller-to-controller disclosure. Terms 13.2 mentions clearinghouses; Schedule 3 lists none. Referral automation lands squarely here — raise it before building.

• Messaging — Twilio is a CONTROLLER, Meta is not. Read this before changing anything.** **Both vendors’ terms were read in full (July 2026). The result is the opposite of what we expected. TWILIO’S OWN DPA, section 3, declares Twilio an INDEPENDENT CONTROLLER of Customer Content (message bodies) and Communications Usage Data (recipient phone numbers, logs, delivery status), for purposes including abuse detection with model training, DEVELOPING AND IMPROVING NEW PRODUCTS AND SERVICES, and BUSINESS ANALYTICS, FORECASTING AND PRODUCT STRATEGY. That is not processor behaviour — it is a vendor reserving commercial rights over our patients’ phone numbers and message content. Twilio’s DPA is already in force automatically (it forms part of their standard agreement), so there is nothing to sign; the issue is what it says, not whether it exists. It also pushes sensitive-data responsibility to us: Twilio’s terms say the CUSTOMER is responsible for safeguards before transmitting sensitive data, and their definition of sensitive data expressly includes health information. Note also SendGrid backups persist for ONE YEAR after termination — longer than our 60-day Retention Period. META, by contrast, contracts as a PROCESSOR: the WhatsApp Business Terms state the business is the Controller and Meta processes on its behalf, and the Cloud API Terms treat phone numbers, message content and message details as Company Personal Data processed by Meta as Processor. Because Barbados is not the US, Canada or Brazil, our contracting entity is most likely META PLATFORMS IRELAND LIMITED — which is a BETTER position, since it brings GDPR-grade processor obligations. Retention is 30 days. (Some practitioners argue WhatsApp is a controller of metadata and is not transparent about it; that is commentary, not Meta’s stated position — note it, do not draft to it.) CONSEQUENCE: DPA 6.7 now discloses the dual-role position, Schedule 3 splits Twilio’s roles, and Privacy Policy §8 tells clinics and patients. THE ARCHITECTURE OPTION: because WE own the WABA, we could go DIRECT TO META’S CLOUD API and drop Twilio from the WhatsApp path entirely. Meta is a processor; Twilio is not. That removes the only vendor claiming controller rights over patient message content. SMS and email would still run through Twilio/SendGrid, and Twilio’s controller rights would still attach to the recipient’s phone number — unavoidable while we use them, which is why it is disclosed rather than fixed. And the standing point remains: keep patient identifiers and clinical content OUT of the message body. “You have an appointment Tuesday at 3pm” carries no Patient Data, and shrinks the problem to the phone number alone.

• DPA 9.3 and 9.5 travel together — do not separate them.** **Clause 9.3 makes a clean, unqualified promise to delete Patient Data and existing copies. That promise is only true because 9.5 bounds it: deletion reaches MedRegis’s systems and sub-processor data we can actually reach; messaging sub-processors (6.7) and AI sub-processors (12.3) retain data on their own schedules; backups age out in the ordinary course and we are NOT required to restore, isolate or purge individual records from them; and Controller Data and De-identified Data sit outside the deletion obligation entirely. An earlier draft hedged 9.3 itself with “within its control”; that was removed because two vaguely different standards read worse than one clean promise bounded precisely — but the consequence is that 9.3 now depends ENTIRELY on 9.5. IF 9.5 IS EVER TRIMMED, SHORTENED OR DROPPED, 9.3 REVERTS TO A PROMISE MEDREGIS CANNOT KEEP: consultation audio sitting in an AI provider’s abuse-monitoring window, and message content in a messaging provider’s backups, are both outside our reach. Do not excerpt 9.3 for a customer without 9.5. Related operational duty: on a deletion request, purge message logs from the messaging providers using their self-service deletion tools — those ARE within our ability to reach, and 9.5 says so.

• Any patient-facing feature.** **A patient portal or patient app breaks the role model. The Terms are B2B, Authorized Users are the Subscriber’s workforce only, and the Privacy Policy states the Service is for users aged 18+. Patients as direct users is a different document set, not an amendment.

• Changing anything Schedule 2 asserts.** **Schedule 2 is a set of LIVE REPRESENTATIONS, not a description written once. Dropping code review, using production Patient Data in a test environment, collapsing dev/prod separation, disabling change logging, or ceasing to maintain — or failing to adopt — the incident response procedure each makes a Schedule 2 statement false on the day it happens — and DPA 10.1 entitles a Subscriber to ask for evidence.

• Personnel or contractors outside Barbados with access to Patient Data.** **That is a transfer, and Schedule 2’s confidentiality and least-privilege entries assume we know exactly who has access. Check before granting it.

• Safe to build — no document change needed.** **Self-service export and deletion (DPA 7.2 and 9.1 are already written conditionally), the AI disable toggle (12.7 likewise), and any within-US infrastructure change. These were drafted to accommodate the roadmap. Build freely.

• Any document change needs the mechanism run.** **Terms 19: post the new version, update the date, give reasonable notice for material changes, and record acceptance of the new version. A revised document that nobody re-accepted binds nobody. Cheap — but it has to actually happen.

Data Processing Addendum

Effective date: 01/07/2026

Error parsing document: undefined method 'close' for nil