Chapter 15 — Privacy and data protection: integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 The new integration"]
N2["15.2 Dependencies"]
N3["15.3 Limiting data"]
N4["15.4 Testing the integration"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 The new integration"]
N2["15.2 Dependencies"]
N3["15.3 Limiting data"]
N4["15.4 Testing the integration"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 The new integration]
|
v
[15.2 Dependencies]
|
v
[15.3 Limiting data]
|
v
[15.4 Testing the integration]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) assess a new integration; (2) map dependencies; (3) limit data shared.
15.1 The new integration
Marlow wants to connect its practice-management system to an online review service that emails patients after appointments asking for a rating. Leila assesses the integration technically before anything is connected. She asks what data the service needs, what it stores, where, for how long, who its subprocessors are and how patients can opt out. The vendor's default integration requests names, emails, appointment types and dentist names, and it publishes reviews with first names and appointment types by default. Leila records each answer in writing.
15.2 Dependencies
Leila maps dependencies: the review service depends on an email delivery provider and a cloud hosting company, both subprocessors. The integration depends on the practice-management system's interface, which changes when the vendor upgrades. A failure in any part could send emails to patients who opted out or publish details they did not expect. She notes that each dependency adds a party who may process patient data and a point where configuration can drift, so dependencies belong in the processing model. Both subprocessors are listed in the contract.
15.3 Limiting data
Leila recommends sending only first name, email and clinic, not appointment type or dentist, because a review request does not need them and appointment types such as implants or orthodontics reveal health information. Publication of appointment types is switched off. Patients who opted out of non-essential messages are excluded at the source by a filter in the export, not by the review service. The data protection officer asks for a legitimate interests assessment and a processor contract before the integration goes live.
15.4 Testing the integration
Leila tests with synthetic patients, including one who opted out and one with an implant appointment. The opted-out patient receives nothing. The implant patient's request contains no appointment type, and a test review is published without treatment details. She also checks that deleting a patient in the practice system leads to deletion in the review service within the agreed thirty days. The integration goes live in one clinic, and Leila schedules a repeat test after the next vendor upgrade. All three tests pass.
Worked example
Leila assesses a review integration, maps subprocessors and interface dependencies, limits shared fields to first name, email and clinic, filters opt-outs at source and tests with synthetic patients.
Synthetic case. The integration is synthetic; GDPR Article 28 contracts and legitimate interests assessments are real requirements.
Errors and limits
Vendors change defaults in upgrades; retest after each one.
Exercises
- EX057 — Default fields. What did the vendor's default integration request? Rubric: 3 = names, emails, appointment types, dentist names;; 2 = most;; 1 = one;; 0 = none.
- EX058 — Appointment type. Why remove appointment type? Rubric: 3 = it reveals health information and is unnecessary;; 2 = mentions health;; 1 = vague;; 0 = none.
- EX059 — Opt-out filter. Where are opted-out patients filtered? Rubric: 3 = at the source export;; 2 = partly correct;; 1 = at vendor;; 0 = none.
- EX060 — Deletion test. What deletion behaviour was tested? Rubric: 3 = deletion reaches the review service within thirty days;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 15 (chapter 15 of 18)
← Chapter 14 · Course chapter index · Chapter 16 →
Continue to the next authored lesson.