Case Study: The Cardiology Birthday Card Incident

Theory: How to Approach These

This case uses every part of Week 7. Each homework question maps to one lesson, so review the matching section before answering.

Confidentiality vs. privacy (see 7.1): ask two separate questions. Did an unauthorized person get the data? (confidentiality) Did the organization collect or use the data in a way patients did not agree to? (privacy). Support each part with a specific fact.
Classification (see 7.2): justify the level with all three criteria: impact if disclosed, legal requirements, data owner expectations. Health information pushes data to the top level.
States of data (see 7.2): trace the data’s journey in order, labelling each step at rest / in transit / in use, and name the missing safeguard for each.
PDPA (see 7.3): check how data was collected and used (consent, purpose limitation, data minimization) and how it was protected (security, controller responsibility for the processor, retention).
Scope (see 7.3): apply location, not nationality. PDPA follows where the data subject is; GDPR follows EU establishment or targeting of people in the EU.
DLP and Privacy by Design (see 7.4): when recommending fixes, think “label it, block the risky route, and don’t collect what you don’t need”.
Apple v. OpenAI is an unresolved lawsuit. Write “Apple alleges…” or “OpenAI argues…”, never state a claim as fact.

The Case

The Cardiology Birthday Card Incident

MediCare Plus Hospital’s Marketing team started a patient-goodwill program: a printed birthday card to every patient treated in the past year. The mailing list was built from registration records: full name, home address, phone number, date of birth and treating department (e.g. “Cardiology”, “Oncology”, “General Checkup”). Patients gave this information at registration so the hospital could contact them about appointments and results.

To print and mail the cards, the Marketing coordinator exported the full list (about 4,000 patients: name, address, phone number, treating department) into a spreadsheet. The file was too large for the internal file-sharing system, so she emailed it from her personal Gmail account to the printing vendor’s project manager. The spreadsheet had no title, no confidentiality label and no password. A copy also remains in the Marketing team’s shared drive, unreviewed for two years, alongside the birthday lists from every previous year.

Two weeks after this year’s mailing, the vendor’s project manager reported that her laptop, containing the spreadsheet, was stolen from her car. The laptop was not encrypted. Anyone who opens the file can see which patients were treated in Cardiology, Oncology or other departments, together with their home address and phone number. Some patients on the list are foreign nationals treated while working in Thailand.

Apple v. OpenAI, Part 2 (discussion case)

This continues Week 6’s discussion. It is a real lawsuit that was still active and unresolved as of September 2026. Everything below describes allegations in a legal complaint and arguments made in response; no court has found that any party did anything wrong.

In July 2026, Apple sued OpenAI and two former Apple employees, alleging misappropriation of confidential trade secrets about Apple’s unreleased hardware: hardware designs, manufacturing methods and supplier information.
Apple’s complaint centres partly on Chang Liu, a former senior Apple systems electrical engineer who, Apple alleges, retained access to Apple’s third-party cloud storage after leaving and used it to download dozens of confidential files, including a circuit schematic.
On August 6, 2026, OpenAI filed a motion to dismiss, arguing the complaint is built on selectively excerpted communications and ordinary conduct taken out of context: that its hardware executive followed normal industry recruiting practice, and that the employee accused of taking files was trying to help a former colleague finish work at Apple’s own request.
The case was reassigned to U.S. District Judge Edward Davila, and the motion to dismiss and Apple’s request for a preliminary injunction were scheduled for a hearing on October 1, 2026. No court has ruled on whether the allegations are true.

Case Questions & Model Answers

Exercise Q1

Is the stolen-laptop incident a Confidentiality issue, a Privacy issue, or both? Identify at least one specific fact from the case to support each part of your answer.

Show solution ↓

Solution

Apply the two tests from 7.1 separately.

Confidentiality: did an unauthorized party get access? Yes.

The vendor’s laptop was stolen from her car and was not encrypted, so the thief (an unauthorized party) can open the spreadsheet and read the names, addresses, phone numbers and treating departments of about 4,000 patients.
Before the theft, the file had already left the hospital’s control: it was emailed through the coordinator’s personal Gmail, outside the hospital’s systems, with no label and no password.

Privacy: did the hospital use the data in a way patients did not agree to? Yes.

Patients gave their details so the hospital could contact them about appointments and results. Using them for a Marketing birthday-card campaign is a new purpose they never agreed to: purpose creep.
The list included the treating department (health information) and phone numbers, far more than needed to mail a card: over-collection / no minimization in what was shared.
Patients’ data was disclosed to a third-party printing vendor for this marketing purpose without their consent.

Note the key insight: even if the laptop had never been stolen, the privacy violation would still exist, because it comes from the hospital’s own decision to reuse the data.

Answer: both. Confidentiality, because the unencrypted laptop holding the spreadsheet was stolen, exposing patient data to an unauthorized person; privacy, because registration data collected for appointments and results was reused for marketing (purpose creep) and shared, including treating department, with a vendor without patient consent.

Exercise Q2

Using the 4-level framework (Public / Internal / Confidential / Restricted), classify the exported spreadsheet. Justify your answer using the classification criteria from lecture (impact if disclosed, legal requirements, data owner expectations).

Show solution ↓

Solution

Apply all three criteria (see 7.2).

Impact if disclosed: severe. Combining name + home address + phone + treating department reveals that a specific, locatable person was treated in, for example, Oncology or Cardiology. This can lead to embarrassment, discrimination, targeted scams or harassment, and the dataset covers about 4,000 patients.
Legal requirements: the treating department reveals health condition, and health data is sensitive personal data under PDPA, held to a higher standard. Disclosure exposes the hospital to administrative fines, civil claims and possibly criminal liability.
Data owner expectations: patients gave these details for appointments and results and expect a hospital to keep their treatment private. The hospital itself, as controller, would never intend this list to be seen outside the care context.

All three criteria point to the highest level. It is not merely “Confidential” (real harm to the organization), because the harm is severe and carries legal exposure through sensitive health data.

Answer: Restricted: disclosure causes severe harm to identifiable patients, the treating department makes it sensitive (health) personal data under PDPA, and patients expect their treatment details to stay private.

Exercise Q3

Identify every state (at rest / in transit / in use) that this data passed through in the case, in order. For each state, name one safeguard from lecture that was missing.

Show solution ↓

Solution

Trace the data’s journey step by step.

#	Step in the case	State	Missing safeguard
1	Patient registration records stored in the hospital’s system	At rest	Data masking / restricted access, so Marketing cannot pull treating department and phone numbers it does not need
2	Coordinator exports 4,000 records into a spreadsheet	In use	Access logging with review, and approval before bulk data export (a DLP rule, see 7.4)
3	Spreadsheet emailed from personal Gmail to the vendor	In transit	Secure transmission channel; policy of no sensitive data over personal channels (and no password or label on the file)
4	Copy kept on the Marketing shared drive, unreviewed for two years, with previous years’ lists	At rest	Secure storage policy with periodic access review and retention/destruction of old lists
5	File stored on the vendor’s laptop, which is stolen	At rest	Encryption at rest: an encrypted laptop would make the stolen file unreadable

(The vendor also used the file in use when printing the cards; the lecture safeguards for that state, such as access logging and session auto-lock, would apply there as well.)

Answer: at rest (hospital records: missing data masking/restricted access) → in use (export: missing access logging and bulk-export approval) → in transit (personal Gmail: missing a secure channel, no personal channels) → at rest (shared drive: missing secure storage policy/access review and retention) → at rest (vendor laptop: missing encryption at rest).

Exercise Q4

List at least two PDPA principles or obligations that MediCare Plus may have violated in this case, and explain why for each one. Consider both how the data was collected and used, and how it was protected.

Show solution ↓

Solution

Check collection/use first, then protection (see 7.3).

How the data was collected and used

Purpose limitation: data was collected so the hospital could contact patients about appointments and results. Using it for a marketing birthday-card program is a different purpose (purpose creep).
Consent: patients never gave informed consent for marketing use or for disclosure to a printing vendor. Because the treating department is sensitive (health) data, the standard is even higher.
Data minimization: mailing a card needs only name and address. Exporting phone numbers and treating department was unnecessary, and turned a mailing list into a health-data leak.

How the data was protected

Security of sensitive data: as controller, MediCare Plus must protect health data at a higher standard. The file had no label, no password, was sent via personal Gmail, and older lists sat unreviewed on a shared drive.
Controller responsibility for the processor: the printing vendor is a processor acting on MediCare Plus’s instructions, but the hospital keeps primary responsibility. It gave no protection requirements (e.g. encrypted devices, deletion after printing). Compare the real case where a private hospital was fined THB 1,210,000 after a vendor’s improper disposal leaked patient records.
Retention / destruction: keeping every previous year’s birthday list for years, unreviewed, means data is held long after the purpose ended. It should be securely destroyed (data lifecycle: archive and destruction).

Answer (any two, well explained): purpose limitation and consent (registration data reused for marketing without consent), data minimization (phone and treating department not needed for a card), and security/controller obligations (unprotected transfer via personal Gmail, no safeguards required of the vendor-processor, old lists never destroyed).

Exercise Q5

Some patients on the mailing list are foreign nationals who were treated in Thailand. Under PDPA Section 5, does their nationality change whether PDPA protects them? Does GDPR apply to this incident? Explain using the “location, not nationality” principle.

Show solution ↓

Solution

Step 1: PDPA. PDPA Section 5 sets scope by where the processing and data subject are, not by citizenship. MediCare Plus is a controller in Thailand, and these patients were in Thailand when their data was collected and used for their treatment. So PDPA protects them exactly as it protects Thai patients. Their nationality changes nothing.

Step 2: GDPR. GDPR also follows location, not nationality. It applies to organizations established in the EU, or to non-EU organizations that offer goods or services to people in the EU or monitor their behaviour in the EU. MediCare Plus is established in Thailand, and it treated these patients while they were working in Thailand; it was not targeting them in the EU. Even if some of them are EU citizens, their citizenship does not bring GDPR with them.

Answer: no, nationality does not matter; PDPA protects all these patients because their data was collected and processed in Thailand by a Thai controller. GDPR does not apply to this incident, because MediCare Plus has no EU establishment and was not offering services to or monitoring people in the EU; GDPR, like PDPA, depends on location, not citizenship.

Exercise Apple Q1

[Confidentiality vs. privacy] Everything in the Apple v. OpenAI case (the schematic, the supplier information, the manufacturing methods) is corporate confidential information. No named individual’s personal data is at stake. Is this a confidentiality case, a privacy case, or both? What would have to be true for it to also be a privacy issue?

Show solution ↓

Solution

Step 1: Apply the definitions (see 7.1). Confidentiality is organization-centric: protecting data from unauthorized access. Privacy is individual-centric: a person’s right to control their own personal data.

Step 2: Classify. Apple alleges that a former employee accessed and downloaded corporate trade secrets after he was no longer authorized. If true, that is unauthorized access to the organization’s information, a confidentiality issue. The information is about products, designs and suppliers, not about identifiable individuals, so as described it is not a privacy issue. (OpenAI argues the conduct was ordinary and in context, which goes to whether there was wrongdoing at all, not to which category the dispute belongs.)

Step 3: What would make it privacy too? Personal data of identifiable people would have to be involved, for example:

the downloaded files contained personal data, such as employee records or named supplier contacts’ details; or
the dispute involved how employees’ own personal data was handled, e.g. if monitoring of staff accounts or devices used to investigate the departures was covert or excessive (the employee-privacy balance from DLP, see 7.4).

Answer: as alleged, it is a confidentiality case only, because the information is corporate trade secrets, not personal data. It would also become a privacy issue if personal data of identifiable individuals were involved, such as employee or supplier-contact records in the files, or employees’ own data collected through monitoring.

Exercise Apple Q2

[Data classification] Using the 4-level scheme (Public / Internal / Confidential / Restricted), where would Apple’s circuit schematic fall, and why? What classification would the same document have if it were a finished product’s public spec sheet instead?

Show solution ↓

Solution

Apply the three criteria (see 7.2) to a schematic for unreleased hardware.

Impact if disclosed: severe. Competitors could copy the design or anticipate the product, destroying a lead built on large R&D investment.
Legal requirements: it is protected as a trade secret, which is precisely why its alleged misappropriation is the subject of a lawsuit; trade-secret protection depends on the owner keeping it secret.
Owner expectations: Apple expects it to be seen only by the engineers who need it.

Severe harm plus legal exposure means the top level, not just “real harm” (Confidential).

Public spec sheet: once a product is released and its specifications are published for customers, disclosure causes no harm, no secrecy obligation applies, and the owner wants people to see it. The same kind of document moves to Public: classification follows impact, not document type.

Answer: the unreleased circuit schematic is Restricted (severe competitive harm, trade-secret legal exposure, strictly need-to-know); a finished product’s published spec sheet is Public.

Exercise Apple Q3

[Data protection lifecycle & DLP] Liu allegedly kept reaching Apple’s cloud storage after leaving, and downloaded files that had been sitting there (data at rest). Which specific safeguard from lecture (encryption at rest, access review, DLP monitoring, or offboarding revocation) would have been most likely to stop this, and at what point in the timeline?

Show solution ↓

Solution

Evaluate each option against the alleged sequence: employee leaves → access remains → files downloaded later.

Encryption at rest: protects against someone who steals the storage itself. But the alleged access came through still-valid credentials, and the cloud service decrypts data for any authenticated user. Would not stop it.
DLP monitoring: could detect an unusual download of dozens of confidential files and raise an alert, but it reacts during or after the download, and works only if the files were classified/labeled. Detects, may not prevent.
Access review: periodic reviews would eventually find an account belonging to someone who no longer works there, but only at the next review cycle, which might come after the downloads. Backup control.
Offboarding revocation: removing all of the employee’s access, including third-party cloud storage, on his last day means there are no credentials left to use. Any later access attempt simply fails.

So offboarding revocation is the most likely to stop it, applied at the moment of departure, before any post-employment access could happen. Access review is the safety net if offboarding misses a system, and DLP monitoring is the detective layer. (Whether the alleged access occurred, and why, is disputed: OpenAI argues the employee was helping a former colleague at Apple’s request. The safeguard analysis holds either way, since it concerns preventing access after employment ends.)

Answer: offboarding revocation, applied at the moment the employee leaves (his last day), is most likely to have stopped the alleged access; periodic access review is the backup, and DLP monitoring would only detect bulk downloads, while encryption at rest would not help against valid credentials.