Privacy Policy — Siriraj Rx Shift (Google Calendar Sync)

Last updated: 3 August 2026 · ดูฉบับภาษาไทยด้านบน

This is a complete English translation of the Thai text above, provided for reviewer convenience. In case of discrepancy, the Thai text is authoritative.

1. Overview

Siriraj Rx Shift ("the app", "we") is an internal duty-roster system for the Pharmacy Department, Siriraj Hospital, Bangkok, Thailand. The Google Calendar Sync feature is an optional, opt-in add-on that mirrors a user's own duty shifts into their personal Google Calendar so they do not have to copy them by hand.

Users who do not enable this feature are never asked for any Google permission and retain full use of the application.

2. OAuth scopes we request, and why

The feature runs in a separate Google Apps Script project and separate Google Cloud project (calendar-sync-app) which requests only these four scopes — exactly matching the app manifest, with nothing additional:

3. What we access, what we store, and where

What appears in a calendar event: date · start and end time · shift type (e.g. "morning shift") · assigned unit or room. Nothing else.

What is never involved: patient data · health information (PHI/PHR) · medical record numbers · clinical records. The system is a staff scheduling tool, not a medical records system, and has never touched such data.

Data flow is one-way: app → the user's calendar. We do not touch events the app did not create, do not access calendars the user did not select, and do not pull any calendar content back into the system. During a sync, the app lists events only within the shift date range on the destination calendar, solely to verify that its own previously created events are still present — it checks only the event ID and the location field, reads no event content, and stores or transmits nothing from any other event.

4. Purpose of use, and Limited Use compliance

The data is used for exactly one purpose: reminding the user of their own work shifts in the calendar they already use daily.

Our use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically we affirm that we do not:

• use the data for advertising of any kind;
• sell, rent, or trade the data;
• transfer the data to third parties, except (a) with the user's explicit consent, (b) for security purposes, or (c) to comply with applicable law;
• allow humans to read the data, except (a) with the user's explicit consent for a specific support issue, (b) for security purposes, or (c) to comply with applicable law;
• use Google Workspace API data to develop, train, or improve any generalized or non-personalized artificial intelligence or machine learning model, whether our own or a third party's. This application makes no AI/ML calls of any kind.

5. Data protection measures

5.1 Encryption in transit

Every network path enforces HTTPS/TLS 1.2 or higher; no plain-HTTP path exists anywhere: user's browser ↔ Apps Script web app · Apps Script ↔ Google Calendar API · Apps Script ↔ Firebase Realtime Database (UrlFetchApp rejects invalid certificates automatically).

5.2 Encryption at rest

All data resides in Google infrastructure (Apps Script PropertiesService, Google Sheets, Firebase Realtime Database), which is encrypted at rest with AES-256 by default. We operate no servers, no databases, and no disks of our own that hold user data at any point.

5.3 Access control — the developer cannot reach users' Google data at all

This is the strongest protection in the design, and it is deliberate:

• The app runs as "execute as user accessing". Every Calendar API call executes as that user, with that user's own credentials — never as the developer.
• There is no service account, no domain-wide delegation, and no server-side API key that would let the developer reach anyone's calendar.
• Mappings and settings live in PropertiesService.getUserProperties(), which Google partitions per user. Opening the Apps Script editor as the developer does not expose another user's properties; no API exists to do so.
• Consequence: even if the developer's account were compromised, the attacker still could not read any user's calendar or mapping data.

5.4 Token handling

We do not store, log, or transmit any OAuth token. Access and refresh tokens are held entirely by Google Apps Script. When a user revokes access at Google Account permissions, authorization ends immediately without requiring any action on our side.

5.5 Project isolation for least privilege

The Calendar feature was deliberately split into its own Apps Script project and its own Google Cloud project, separate from the main system. The main system (which holds higher-privilege scopes used only for administrator back-office tasks) and the Calendar project share no credentials whatsoever. A user connecting their calendar is therefore asked for exactly the four scopes in §2 and nothing from the back-office side.

5.6 Roster data in Firebase (feed / ack)

calFeed holds a user's shift list keyed by their internal display name (not an email address, not a Google ID). Its contents are the same roster information that every member of the department already sees on the shared duty roster as a matter of normal operation. calAck holds only summary counts (how many events were created/updated/deleted, and when) — no event content.

The database is in region asia-southeast1 (Singapore), encrypted at rest, and holds no data obtained from Google APIs whatsoever — no tokens, no event IDs, no calendar content.

5.7 Logging and auditability

Every script execution is recorded automatically in Google Cloud Logging (Stackdriver), as configured for the project, and each sync run writes an acknowledgement record (calAck) with a timestamp and the number of events created, updated, and deleted — so it is always auditable how many calendar changes were made and when. These records never contain event content and never contain tokens.

5.8 Retention and deletion

Pressing "Disconnect" in the app (1) deletes every event this app created from the user's calendar, (2) deletes the mappings and settings from PropertiesService, (3) deletes the installed trigger, and (4) revokes the script's authorization — all from a single button press. (If a specific event cannot be deleted at that moment — e.g. the calendar is temporarily unreachable — the user is informed, and the mapping for that one event is retained so deletion can be completed on a later attempt rather than leaving an orphaned event behind.)

5.9 Breach response

If we become aware of an incident affecting user data, we will (1) suspend the feature and revoke authorizations immediately, (2) notify affected users by email and via in-app announcement within 72 hours of becoming aware, and (3) notify Google through the designated channel if the incident involves data obtained from Google APIs.

5.10 Personnel with access

The system is built and maintained by a single developer (the contact in §9). There are no employees, no subcontractors, and no third parties with access. The developer's Google account that owns the project has 2-Step Verification enabled.

6. Third-party sharing

We share no Google API data with any third party. There are no analytics services, no trackers, no advertising, and no external CDN that receives user data. The only data processor is Google LLC, as the infrastructure provider (Apps Script, Calendar, Firebase).

7. User rights

Users have the right to access, correct, obtain a copy of, object to the processing of, and delete their data, under Thailand's Personal Data Protection Act B.E. 2562 (PDPA). All of it can be exercised immediately and without contacting us:

1. Disconnect in-app — the "Disconnect" button on the "Calendar settings" screen deletes every event created, deletes all stored data, and removes the trigger.
2. Delete events only, staying connected — the "Clear all shift events" button.
3. Revoke from Google's side — at Google Account permissions, select "Siriraj Rx Shift Calendar" and remove access.
4. Turn off automatic updates only — the "Automatic updates" toggle (removes the trigger; already synced events remain).

Deletion requests and other enquiries: the email in §9. We respond within 30 days.

8. Children

The system is used exclusively by licensed pharmacy professionals. It is not designed for or directed at anyone under 18, and we do not knowingly collect data from minors.

9. Changes to this policy, and contact

If we make material changes we will update the "Last updated" date above and notify users through an in-app announcement.

Data controller / contact: Norapol Uttho — norapol.uttho@gmail.com
App website: https://sirxshift.com/