Privacy Policy

_Last updated: 14 September 2026_

This Privacy Policy explains what information the CareClinic platform ("the platform", "we", "us") collects, why we collect it, how it is used and protected, and the choices you have. It covers the public portal, each clinic's website and management system, the mobile app for doctors, and the Company Portal for employers and HMOs.

Who is responsible for your data. Each clinic using the platform is the controller of its patients' and staff's information — it decides what is collected and how it is used in caring for patients. The platform operator acts as a processor, hosting and safeguarding that information on the clinic's behalf. For the public portal and platform accounts, the platform operator is the controller. If you are a patient, the clinic you visit is your first point of contact for questions about your records.

1. Who this policy applies to

• Patients of clinics that use the platform.
• Customers of a clinic's pharmacy counter who buy something over the counter without being a patient of that clinic.
• Doctors, nurses and clinic staff who use the clinic management system or the mobile app.
• Visitors to the public portal and to a clinic's public website.
• Clinic owners and administrators who manage a clinic on the platform.
• Company administrators and HR users who use the Company Portal on behalf of an employer or HMO.

2. Information we collect

2.1 Account and identity information

For people who sign in to the platform (doctors, staff, administrators):

• Name, email address and contact number.
• A username and password. Passwords are never stored in readable form — only a securely hashed version is kept.
• The role assigned to the account (for example, doctor, nurse, receptionist, cashier or administrator).
• Display preferences you set for yourself, such as whether the clinic system appears in its light or dark colour scheme. This is a preference on your own account and is not information about a patient.
• For platform administrators, and for any clinic account that turns it on, an additional one-time security code (two-factor authentication) setup — the shared secret for the authenticator app, and the recovery codes, held in a form we cannot read back to you.
• Where you work at a pharmacy counter, a short PIN for signing in at that counter. Like a password, it is never stored in readable form — only a securely hashed version is kept. You normally set it yourself after confirming your password. A clinic administrator may also set or remove one for you, for the practical case of somebody who cannot set their own; when that happens, the record keeps who set it and when, and you are sent the PIN in an in-app notification so you do not depend on someone reading it out. Those digits are the one point at which a PIN is held in readable form, and they are destroyed the first time you open that notification — and in any case within 24 hours, whether it is opened or not. You may change the PIN yourself afterwards. You can remove it at any time without affecting your account. Setting, changing or removing a PIN signs you out of the platform, so the previous one cannot still be in use somewhere.

2.2 Patient personal information

When a clinic registers a patient, it may record:

• Name, date of birth and sex.
• Contact details such as phone number, email and address.
• Civil status, where recorded.
• An internal patient reference number, and any reference number the clinic was given for you by an employer or a school.

All of these are stored in an encrypted form, with the exception noted in section 5.2.

Sex is asked for whenever a member of staff registers a patient, because the clinic's own counts and age-and-sex reporting depend on it. The public booking form is the one exception: it does not ask, and nothing is assumed on your behalf — the clinic completes it when it registers you.

A clinic may also register a group of people at once by uploading a spreadsheet — for example a list an employer or another organisation gives it. Only the details in that spreadsheet are taken, and only those the clinic chooses to use: they may include name, date of birth, sex, email, phone number, address, civil status, a record ID number, and fields the clinic has defined for its own patient records. The clinic reviews what was read from the file and chooses which rows are registered before anything is created, and people already on file are left unchanged. Whoever supplies such a list is responsible for having the authority to share it.

2.3 Health information (sensitive)

In the course of care, a clinic may record health information about a patient, including:

• Consultation notes, findings, diagnoses and treatment plans.
• Prescriptions and medicines issued, including the generic name recorded for each, and — where a controlled medicine is prescribed — the serial number of the PDEA Yellow Prescription Form it was written on and the prescribing doctor's S2 licence number.
• Laboratory test orders and results.
• Imaging orders, the images themselves — X-rays, scans, ultrasounds — and the radiologist's report on them: the clinical indication, technique, findings, impression and recommendation.
• Dental charts — the condition recorded for each tooth and each of its surfaces, kept per visit, for adult and for children's teeth alike.
• Appointment and visit history.

Health information is the most sensitive data the platform holds and is given the strongest protection (see Section 5).

Examination results imported from a spreadsheet. A clinic that has examined a group of people — for example in an annual physical examination carried out for an organisation — may bring the results in by uploading a spreadsheet instead of entering each one by hand. Only staff permitted to manage the clinic's settings can do this, and only the columns the clinic chooses to use are taken. For each person the import can record:

• the personal details described in section 2.2, when the person is not already on file;
• a visit on the examination date with the examining doctor the clinic selects — with blood pressure, a body-mass-index note and the complaints listed when the row has results, or as a pending visit when it has none;
• blood count, urinalysis and hepatitis B screening results, filed as laboratory results;
• a findings summary on the person's record, including ECG, chest X-ray and remarks;
• where a remark describes the person's employment status rather than a health complaint (for example that they have resigned or are on leave), that status as a field on their patient record.

The clinic reviews every row on screen before anything is saved, and can remove rows or leave columns out. Importing the same file again does not create duplicate people, and no second visit is added for someone an earlier import gave a visit in the 15 days before the examination date; their results are added to that visit instead. The clinic may name the organisation the examination was carried out for, which links each person to it; that link is optional, and where it is made, what the organisation can see is governed by section 6. Whoever supplies the spreadsheet is responsible for having the authority to share it, and the clinic remains responsible for the results it records.

Images are held as files, and are marked. A scan is not a row in a table; it is a picture, and a picture of a person can identify them on its own. Imaging files are kept outside the public web root and are only ever served through the clinic's login, to someone whose role permits it. Every copy shown to anyone other than the staff who take and read the studies — in the viewer, in the printed report, on your own portal — has the clinic's name, your name and the study date drawn across the image. That marking does not stop a screenshot; it makes an escaped copy traceable to where it came from. The original, unmarked file is reachable only by the staff who perform or report imaging.

Health entries recorded by an employer or HMO. Where you are linked to a company that uses the employer portal (section 6), a user of that portal can record health entries about you — a medical note, medication you have reported, a medical undertaking, or other health information. These are the company's own record of what it has been told, kept so the clinic and the company are working from the same context. Two things follow:

• They are not a clinical record and not a prescription. They do not become part of what your doctor has diagnosed, prescribed or ordered; only your clinic can record that.
• Each entry carries a visibility the author chooses: visible to the company only, to the clinic only, or to both. An entry marked for the clinic appears on your record there. Entries are stored encrypted with your clinic's own key, on the same footing as the rest of your health information.

A controlled medicine is marked on the printed prescription. Where your clinic has classified a prescribed medicine as a dangerous drug, the printed sheet says so plainly, together with the form number it was written on. This is a legal requirement of how such prescriptions are dispensed, and it is worth knowing that it makes the paper more revealing than an ordinary prescription: anyone who sees the sheet can tell that a controlled medicine was prescribed, though not why. Treat it as you would any medical document — and see section 5.2 on information that has left the platform.

A record that the prescription was checked. When a prescription is written, the platform checks it against the prescribing rules the clinic has configured — that a generic name is present, that a controlled medicine carries a form serial, and so on — and stores what it found alongside the prescription. That record holds the rule names, the outcome, and the medicine each finding relates to. It is kept because "was this checked, and what did it say at the time" is the question an audit asks, and it is never recalculated afterwards.

2.4 Billing and financial information

• Charges, payments, receipts and outstanding balances for services rendered.
• A clinic's subscription plan, add-ons and platform invoices.

The platform does not store full payment-card numbers. Payments recorded in the system are entered by clinic staff as a record of money received.

Billing records outlive a deletion request. If a patient's records are deleted (see section 7), the charges, payments and receipts remain in the clinic's accounts, but the patient is de-identified: the entries appear against a label such as "Deleted patient #4" rather than a name. This is deliberate — a clinic has legal and accounting obligations that continue after a patient asks to be forgotten, and removing the entries would change what the business recorded as earned.

2.5 Booking, portal messaging and enquiry information

Portal messaging is a feature each clinic chooses. It is switched off unless the clinic turns it on, so a clinic that has not enabled it exchanges no messages with its patients through the platform and none of the message data below exists for it. A clinic that switches messaging off later keeps the messages already exchanged, as part of the patient record, but no new ones can be sent by either side and the conversation is no longer displayed.

• Appointment requests made through a clinic's website or the public portal, including the name, contact details and preferred time provided by the requester.
• Messages exchanged between a patient and clinic through the secure portal,

including the message text, sender name, sender type, time sent, read status, patient record, and an appointment reference where one applies. A message may contain health information even though the clinic asks patients to use the channel for administrative questions.

• The portal access grant that connects the verified patient to the conversation,

including its expiry and verification state.

• Messages sent through the public contact form.
• Doctor registration requests, including the information a doctor submits to join or open a clinic.
• Company bulk-booking campaign requests submitted by a Company Administrator to a clinic already linked to that company. These include the selected clinic, requested date window and preferred time, an optional doctor, the association reference for an existing patient or the contact details entered for a new person, any request notes, and the submission record.
• A record of your agreement. Where you tick the box accepting the Terms of Use and this policy — when requesting an appointment, or when registering as a doctor — we store the date and time you did so, alongside that request. It is kept for as long as the request itself, and is used only to show when the agreement was made.

2.6 Public listing information

If a clinic or doctor opts in to be listed publicly, a limited profile — such as the clinic or doctor name (the display name, where one is set), specialty, the services offered and the doctor's profile photo where one has been uploaded — is shown on the public portal so patients can find them. A doctor's own e-mail address and phone number are not shown on their public profile; the contact details on a clinic's page are the ones that clinic chooses to publish.

A doctor who does not want their photo published can remove it from their profile, or switch their public listing off entirely.

This is optional and there are two switches: the clinic can turn its own listing off in its settings, and each doctor can be excluded individually. Turning either one off removes the doctor from the directory, from the search results and from the home page.

2.7 Document verification records

Documents a clinic prints — prescriptions, medical certificates, annual physical examination forms, pharmacy invoices, counter receipts and reports — carry a QR code that lets someone confirm the document is genuine (see section 6.2). For each document we keep a small record separate from your health record, containing:

• What kind of document it is, and a short non-clinical description of it (for example, "3 prescribed items"). For a pharmacy counter receipt this is the words "Pharmacy Receipt" and the order's tracking number — never a list of what was bought.
• Your name reduced to initials — the first letter of each of your names, each followed by asterisks in place of the remaining letters. Your name is never stored here in full.
• The issuing clinic and doctor, the document's reference number, and the dates it was issued and printed.
• A count of how many times the code has been scanned, and when it was last scanned. This is not linked to who scanned it — no account, no name, no IP address is kept against a scan.

This record deliberately contains no health information, and your full name is never written into it.

The certificate itself is a different document from this record, and it can now carry clinical detail. At the issuing clinician's choice, a medical certificate may include the vital signs recorded at the visit, the diagnosis and treatment, and any consultation notes, laboratory results and imaging findings the clinician selected individually for that certificate. The clinician chooses each one — nothing beyond the fields your clinic's own template asks for is ever added automatically. This does not change what is written above: the verification record described in this section still holds no health information and still reduces your name to initials, whatever the certificate itself contains.

The template may also include APE assessments and consultation observations or recommendations. Visit fields fill from the source records requested by the template; notes and results require the issuer to select them. An appointment-linked certificate uses that appointment's records. Without an appointment, the platform can use your latest intake, APE and consultation observations or recommendations, which may come from different dates. Consultation diagnosis and treatment require an appointment-linked medical record. Appointment notes are available only for the linked appointment.

For selected laboratory results, the platform requires validation and a final or amended status. Selected imaging reports must be signed, final or amended, with no unreviewed amendment pending. The clinic must have the corresponding module enabled, and the issuer must have permission to view that information. These eligibility checks do not decide which information the clinic should disclose to the recipient.

The clinic saves the certificate body as rendered at issuance. Later changes to source records do not update that saved body. Automatic page fitting adjusts the body's text size; it does not remove selected clinical information or reduce what a recipient can read. Ask your clinic about the contents or correction of a certificate it issued. The QR verification page does not provide access to that clinical body.

2.8 Technical and usage information

• Sign-in activity and security events (for example, repeated failed sign-in attempts), used to protect accounts.
• Basic request information such as the page requested and the time, kept in system logs. Health information is deliberately kept out of these logs.
• Session cookies that keep you signed in, and a security token that protects forms against misuse.
• For the mobile app, a device notification token so the app can receive push notifications.
• Where a member of clinic staff has asked to be notified about a particular patient, a record of that request: who asked, which patient, and which kinds of event. It is held for the clinic, is visible to the clinic's administrators, and contains no health information.
• Where a clinic runs a pharmacy counter, a record of each machine it has enrolled for counter sign-in — a name the clinic gives it, who enrolled it, and when it was last used. This records a piece of clinic equipment, not a person, and it is what lets a clinic revoke a lost device immediately.
• Where a clinic runs a Health Board, an essential display cookie that authorizes that browser for 90 days after someone enters the display PIN or opens the clinic's kiosk link. The cookie contains an expiry, random value and signature, not a patient name, patient ID, appointment ID or staff account. Changing the PIN, rotating the kiosk link or signing out all screens invalidates it.

2.9 Buying something at a clinic's pharmacy counter

A clinic can sell medicine and supplies over the counter. You do not have to be a patient of that clinic, and you do not have to give your name. If you do give one, this is what is kept and why.

• What you bought, when, what it cost and how you paid. This is the clinic's record of the sale, and it is kept for the same accounting and medical-supply reasons as the rest of its books.
• A name and contact detail, only if you give them. They are asked for so the clinic can find your order again — to hand it over, to take payment for it later, or to deal with a return. A sale can be completed with neither, and an unnamed sale is recorded as a walk-in customer with nothing identifying attached.
• Nothing is verified. A name given at a counter is taken as given. The platform does not check it against anything and does not try to match you to a patient record.

Two points deserve to be stated rather than left to be inferred:

This is health information about you, and it is treated as such. What medicine a named person bought says something about their health, so the name and contact you give at a counter are stored encrypted with the clinic's own key, to the same standard as a patient's name and by the same means (section 5). They are not held to a lower standard merely because you are not a patient.

A counter sale is not a medical record. It does not create one, it is not added to a record you may have at that clinic, and it is not visible to any employer or HMO portal. If you are a registered patient and the purchase is billed to your account, the charge appears in your billing record at that clinic like any other charge.

Where an item requires a prescription, the clinic must attach one before the sale can be completed. That link is the clinic's record of what it dispensed against; see section 2.3 for prescriptions themselves.

2.10 Waiting-room Health Board

A clinic can place a live Health Board on a TV or tablet in its waiting room. The board uses today's appointment information to show who is being served and who is waiting. It shows an encounter reference number by default, together with the doctor's name and the visit type. A clinic can instead choose a first name and initial, or a first initial and surname. It can also show doctor availability and the clinic's services.

The board never sends a patient record ID or appointment ID to the display. It does not create another copy of the queue in the database. The screen requests a fresh view every 20 seconds and keeps the last successful view if a request fails. Anyone who can see the waiting-room screen can see the labels on it, so the clinic controls the label format and where it places the display.

The clinic can upload its own images and muted MP4 clips. If it chooses a YouTube or Vimeo slide, the display device contacts that provider to load the video. The provider can receive ordinary connection information such as the display's IP address and browser details. No queue or patient information is placed in the video URL or sent to the provider by the platform. A clinic must not choose a video, title or provider account that reveals patient information.

3. How we use information

We use the information above to:

• Provide the clinic management system, public portal and mobile app.
• Let clinics care for their patients — recording visits, prescriptions, tests and billing.
• Let clinics show a limited view of today's queue on their own waiting-room Health Board, using the identity format the clinic selected.
• Allow patients to find clinics and request appointments online.
• Let patients and authorized clinic staff exchange secure messages about the

patient's care and clinic administration.

• Let a company request a group of appointments from a clinic it is linked to, while leaving the clinic to decide whether and when each appointment is created.
• Send transactional messages such as appointment confirmations, reminders, verification emails and account notices.
• Send calendar invitations for confirmed appointments, so the visit appears in your own calendar and your device can remind you (section 6.1).
• Send a reminder of an upcoming appointment to the address your clinic holds for you, about a day before the visit (section 6.1).
• Send service notices about the platform itself — a change to these documents, planned maintenance, a security matter (section 6.3).
• Alert a member of clinic staff about a patient they have asked to follow, in the clinic system and on the mobile app (section 5.5).
• Protect accounts and prevent abuse (for example, anti-spam checks and sign-in protection).
• Operate, maintain, support and improve the platform.
• Meet legal, regulatory and record-keeping obligations.

We do not sell personal information, and we do not use health information for advertising.

3.1 The legal basis for each use

The Data Privacy Act of 2012 (RA 10173) requires that every use of personal information rest on a lawful basis, and it treats health information as sensitive personal information, which may only be processed on one of the narrow grounds in section 13 of the Act. The bases relied on here are:

• Your health record, held by the clinic treating you — section 13(d): processing by a medical practitioner or medical treatment institution, for the protection of your health, carried out with adequate confidentiality safeguards and used only for medical treatment purposes.
• Your health record, hosted by us for that clinic — the same basis, exercised through the clinic. We are its Personal Information Processor and act only on its instructions.
• Your name and contact details, used to care for you and to reach you about it — section 12(b): necessary to fulfil the service you and the clinic have entered into.
• Patient portal messages: sections 12(b) and 13(d), communication needed

for the clinic service and, where the message contains health information, processing by the clinic caring for you under confidentiality safeguards.

• Booking requests, doctor sign-ups and public listings — section 12(a): your consent, recorded with a date and time as described in section 2.5.
• Company bulk-booking requests for people already linked to that company — the lawful basis recorded by the clinic for that company-patient association. If consent is that basis, withdrawing it prevents the company from submitting a further request for that person.
• A purchase at a pharmacy counter — section 12(b): the name and contact you give are necessary to complete and hand over the sale you asked for. The record of the sale itself is kept under sections 12(c) and 13(b), below.
• Billing, tax and medical record-keeping — sections 12(c) and 13(b): compliance with a legal obligation.
• Account security, anti-abuse and fraud prevention — section 12(f): the legitimate interests of the clinic and the operator, weighed against your rights.
• Emergencies — section 13(c): to protect your life and health where you are not legally or physically able to give consent.

Where consent is the basis, you may withdraw it, and withdrawing it stops that use going forward. Withdrawing consent does not erase a medical record, because a clinic's duty to keep one does not depend on your consent — see section 8.1.

4. Cookies and similar technologies

The platform uses a small number of strictly necessary cookies:

• A session cookie to keep you signed in. Each clinic's site uses its own separate session.
• A security token to protect form submissions.

These are essential to the service and are not used to track you across other websites.

5. How information is protected

• Access control. Each person signs in with their own account and only sees what their role allows. A clinic account must also be linked to an active doctor or staff record at that clinic before it can enter the clinic system. This stops a role assignment or account copied from another clinic from becoming access on its own. The platform administration area always requires an extra two-factor security step, and clinic staff can turn one on for themselves — a code from their phone on top of their password. A clinic can require it of whichever roles it chooses, and anyone who turns it on is given single-use recovery codes so a lost phone is not a lost account.
• Encryption in storage. Patient information is stored in an encrypted (scrambled) form — both the medical details and, since 6 August 2026, the details that identify the person: name, email address, phone number, home address and date of birth. The name and contact given by a walk-in at a pharmacy counter (section 2.9) are encrypted the same way and with the same clinic key. Each clinic has its own separate encryption keys, so its data cannot be read with another clinic's keys. Section 5.2 explains what this does and does not protect against.
• A large file uploaded to a patient's record — an image, a scan, a document — may be transferred in parts rather than all at once. While that transfer is happening, the incomplete file is held temporarily on the clinic's own storage, kept outside the area the internet can reach and readable only by the clinic's own application — never by a browser directly. It becomes part of the record only once the transfer finishes; an interrupted or abandoned transfer never does. See section 7 for how long the incomplete file is kept.
• Encryption in transit. Where the platform is served over the internet, traffic is protected with HTTPS.
• Strict separation between clinics. One clinic can never see another clinic's patients or records. This separation is enforced at several layers of the system.
• Sign-in protection. Repeated failed sign-in attempts are slowed and blocked to deter intruders.
• Minimised logging. Health information is excluded from system logs and error messages.
• A trail that cannot be quietly edited. Each entry in the record of changes is cryptographically linked to the one before it, so altering an old entry or removing one is detectable rather than merely against the rules. Stated honestly: this makes tampering visible, not impossible — someone with direct access to the database could rewrite the whole chain, which is why each period is additionally sealed with a key held outside the database, and why those seals can be exported and kept somewhere the operator cannot reach.
• A record of who opened your record. Changes to a record have always been logged. Since 6 August 2026 the platform also records who opened one — the person, the part of the record, and when, but never what it said. Your clinic can show you that history on request, and it is what lets a clinic investigate a suspicion rather than guess. A read from an employer or HMO portal is recorded in the clinic's own trail, so the clinic can see who outside it has looked. The trail itself is kept for a limited period and then removed, because a permanent record of who consulted whom would become its own problem.

No system can be guaranteed perfectly secure, but the platform is built and maintained to protect your information using current good practices.

5.1 Archive files

A clinic can ask for an archive of its own data, and one is produced automatically before records are deleted (section 7.1). This makes a copy of the information, so it is worth being clear about how that copy is handled:

• It is made available on a single secret link that expires after 10 days, after which the file is deleted and the link stops working. There is no sign-in behind the link, so the link itself should be treated as confidential.
• The link is emailed to the person who asked for the archive.
• The archive contains the encrypted fields exactly as stored, without the keys that unscramble them. It is therefore a restore file rather than a readable export — anyone obtaining it could not simply read the sensitive fields out of it.
• An archive of one patient's records contains only what that clinic holds. It does not include notes or documents belonging to an associated employer or insurer.
• An archive of a company's portal contains the company's own records — its users, its links to patients and its own notes — and not the clinical records held by clinics.

5.2 What encryption in storage does, and does not, protect against

We would rather be precise than reassuring, so this section says plainly where the protection ends.

What it protects against. Somebody who obtains the stored files themselves — a stolen backup, a copy of the database, a discarded disk, a hosting provider's staff — cannot read the encrypted fields from them. Without the clinic's keys, the name, contact details, address, date of birth and every medical field are unreadable. This is the situation the encryption exists for.

What it does not protect against.

• A signed-in account. Anyone using a valid account sees exactly what that account is allowed to see, in readable form — that is the point of the account. Passwords, shared logins and unattended screens remain the most important thing your clinic controls.
• Two fields that are deliberately readable-ish. So that a clinic can still count patients by sex or by age group, sex and civil status are stored as a fixed scrambled code rather than as free text, and the year of birth is stored on its own in readable form. A code that is always the same for the same value can be worked out by someone studying a stolen copy — there are only three possible values for sex — and a year of birth on its own identifies nobody, but neither is secret in the way a name now is. Everything else, including the full date of birth, is not stored in a form that can be worked out this way.
• Information you send elsewhere. A document you download, print, email or hand to an employer has left the platform and is no longer covered by any of this.

5.3 Being able to find a patient again

Encrypting a name would ordinarily make it impossible to search for. So that your staff can still find a patient by typing part of a name, the platform keeps a short-lived working copy of just the searchable details — names, email, phone, date of birth, and nothing clinical.

• It is held in memory only, for a matter of minutes, and never written to disk.
• It is itself encrypted with the clinic's own key.
• It is never included in an archive or export, and it disappears on its own.

The platform also stores, for each patient, a one-way code derived from certain values — an email address, a phone number — which lets it match an exact value without storing that value in readable form. A code of this kind cannot be turned back into the value it came from, and the codes of two different clinics never match each other, so nothing can be correlated across clinics.

5.4 If something goes wrong

If personal information is exposed, lost or accessed without authority, and the breach involves sensitive personal information or anything that could enable identity fraud, and there is a real risk of serious harm:

• The National Privacy Commission is notified within 72 hours of knowledge of the breach, as NPC Circular 16-03 requires, and the affected people are notified as well.
• The notification says what happened, what information was involved, what is being done about it, and who to contact for more.
• Where the breach concerns a clinic's records, the operator notifies the clinic within 24 hours so the clinic — as the controller — can meet its own 72-hour duty, and the operator assists with the notification and the investigation.

Notification to the affected people may be delayed only where the Commission allows it, for example while doing so would hinder a criminal investigation.

Every security incident is recorded in a register — including the ones judged not to require notification, together with the reasons and the date that judgement was made. Keeping the near misses is the point: a decision not to notify is only defensible if it was written down at the time rather than reconstructed afterwards, and the annual report to the Commission is produced from that register. The register holds no patient information; an entry says what kind of information was involved, never the information itself.

5.5 Alerts about a patient carry no health information

A member of clinic staff may ask to be notified when something happens to a patient they are following. What is sent, and what is stored, says only the kind of thing that happened — that a charge was recorded, that a laboratory result was validated, that an imaging report was signed — together with a link back to the record. An alert about imaging never carries the finding, the impression, or the images themselves.

• No name and no clinical detail appear in the alert, on screen, on a phone's lock screen, or in the stored message.
• The link opens the record with the permissions the person already has, and that visit is written to the record access log in the usual way (section 2.2). Asking to be notified grants no access.
• Someone who may not open a patient's record may not ask to be notified about it.

5.6 Patient messages stay inside authenticated records

Messaging exists only where a clinic has switched it on. Where it is off, no message can be sent or received, and the surfaces described below are not shown to anyone.

The platform encrypts the sender name and message body with the clinic's tenant key before storing them. Authorized staff read the conversation after signing in to Clinic IMS. Patients read it after opening their portal grant and entering the one-time code sent to the email address on their record.

• The Clinic IMS alert bar can show the patient name and a short message preview

to staff with the patients.view permission. It shows no more than three unread messages at a time.

• Email and mobile push alerts say that a patient sent a message. They do not

include the patient name or message text.

• Application logs, error responses, and patient-message event payloads do not

contain the message body or patient name.

• Opening the conversation records the relevant patient messages as read. The

platform stores that read time with the message.

6. How information is shared

Information is shared only as needed to run the service:

• Within your clinic, with authorized staff who need it to provide care or run the clinic.
• With service providers who help operate the platform, limited to what they need:
• an email delivery provider, to send transactional emails and calendar invitations;
• a push-notification provider, to deliver mobile app notifications;
• an anti-spam provider, to protect public forms from abuse;
• hosting infrastructure that stores the platform's data.
• With YouTube or Vimeo, only when a clinic chooses that provider for a Health Board slide. The display device requests the video player and sends ordinary connection information, but the platform does not send the queue or patient information to the provider.
• When required by law, such as a valid legal request or to protect safety and rights.
• On the public portal, only the limited listing information a clinic or doctor has chosen to make public.
• With an employer or insurer, where you are linked to a company that uses the platform's employer portal. What that company can see is limited to a defined set of fields and never includes a clinic's private notes. The company can also record health entries of its own about you, as described in section 2.3, and chooses whether each one is shared with your clinic. Your clinic records on what authority it shares with each company — your consent, an obligation under employment law, treatment or insurance administration, a legal claim, or protection of life and health — and, where it is your consent, the date you gave it. You can withdraw that consent by telling your clinic. From the moment the clinic records it, the company stops being able to see you at all; the withdrawal is enforced by the system rather than left to be remembered. See section 8.2 for what a company can and cannot ask for.
• With a clinic receiving a company bulk-booking request, only the information needed to review that request. A Company Administrator can submit a request only to a linked clinic and only for a person whose association permits the sharing. The request is not an appointment or a medical record; the clinic decides whether to create or schedule an appointment.
• As an archive file, when a clinic requests one or when records are about to be deleted — delivered by a secret expiring link as described in section 5.1.
• To your own calendar provider, if your clinic sends calendar invitations and your email is handled by that provider. See section 6.1.

6.1 Calendar invitations

If your clinic has enabled it, confirming an appointment sends you a calendar invitation attached to the confirmation email. Where your email is handled by Google — a Gmail address, or a work address on Google Workspace — Google adds the appointment to your calendar automatically and reminds you before it starts. Rescheduling updates the entry and cancelling removes it.

The day-before reminder carries the same invitation. Around 24 hours before an appointment, a reminder is emailed to the address your clinic holds for you, and the appointment travels with it as a standard calendar attachment. This reaches you whatever handles your email: on a Gmail or Workspace mailbox the entry is filed automatically, and elsewhere it arrives as a file you can open to add it yourself, or ignore. Where the visit is already on your calendar from the confirmation, the reminder updates that entry rather than adding a second one. A clinic that has switched calendar invitations off still sends the reminder email, without the attachment.

Some points worth being clear about:

• Nothing is connected to your Google account. You are never asked to sign in, grant access, or link anything. The invitation is an ordinary email attachment in a standard format, and it is your own mail provider — not this platform — that acts on it. The platform holds no access to your calendar and cannot read it.
• What the invitation contains. The date, time and length of the appointment; the clinic's name, address and phone number; and the name of the doctor you are seeing. It contains no health information — no reason for the visit, no complaint, no diagnosis, no notes, and nothing else from your record.
• This means your calendar provider sees it. An invitation delivered to a Gmail or Workspace mailbox is processed by Google, in the same way Google already processes every other email sent to that address. Booking an appointment at a named clinic can itself suggest something about you, and that is the trade being made in exchange for an automatic reminder.
• How to avoid it. Give the clinic an email address that is not handled by Google, or ask the clinic to turn calendar invitations off. You can also delete the calendar entry at any time from your own calendar — that is your copy, and removing it does not affect your appointment.

Invitations to doctors. A clinic can separately choose to send its doctors a calendar entry for the appointments they are booked for. Where a doctor's email is handled by Google, that entry — which names the patient the doctor is due to see, and nothing else from the record — is processed by the doctor's mail provider. This is off unless a clinic turns it on, and it is a decision for the clinic: doctors using personal rather than clinic-issued mailboxes is the case that most deserves thought. Clinics are responsible for making that choice appropriately for the people in their care.

6.2 Document verification codes on printed documents

Documents your clinic prints for you carry a QR code, next to the doctor's signature. Scanning it opens a page that asks for the separately printed document reference; together, those two details confirm the clinic really issued the document.

Because a printed page can be dropped, photographed or passed on, that page is written for a stranger to see:

• What it shows. The issuing clinic, what kind of document it is, a short non-clinical description ("3 prescribed items"), the doctor's name and licence number, the reference number, and the dates it was issued and printed.
• Your name appears only as initials — the first letter of each of your names, with asterisks in place of the rest. Someone who does not already know whose document it is cannot learn your name from the page.
• It never shows health information. No diagnosis, no medicines, no laboratory results, no fitness verdict, no notes. There is no way to reach your record from it.
• The code is not a password. It confirms a document exists and who issued it; it unlocks nothing and grants access to nothing.
• Anyone holding the paper can scan it. That is the point of the feature. Treat a printed medical document as you would any other — the code is only as private as the page it is printed on.

A clinic can revoke a document, for example if it was issued in error or the paper was tampered with. A revoked document does not pass verification, and the response remains generic so it does not disclose document details. The paper itself does not change; ask the issuing clinic if a document cannot be verified.

6.3 Messages from the platform operator

Almost every email you receive comes from your clinic's system on your clinic's behalf — a booking confirmation, a reminder, a portal link. Separately, the platform operator can email people directly about the platform itself: a change to these documents, planned maintenance, or a security matter you need to know about.

• Who can be written to. Clinic administrators, doctors and staff who hold accounts; users of an employer or HMO portal; and, for genuine service notices only, patients of clinics on the platform. A message can be limited to particular clinics.
• The address used is the one already held for you — on your account, or on your patient record at your clinic. Nothing new is collected in order to send it.
• Recipients never see one another. Each message is sent individually. Nobody is copied in, so no recipient learns another recipient's address.
• No advertising, and no selling. These are notices about the service, not marketing. We do not sell addresses and we do not pass them to anyone for their own use.
• What is kept. A record of each message sent — its subject, its contents, who it was addressed to as a group, how many people received it, and which administrator sent it. It is kept as the answer to "what exactly went out, and to whom", and holds no health information.

If you are a patient and you would rather not receive these, tell your clinic: your address is on your clinic's record, and your clinic controls it. Messages that are essential to a service you are using — an appointment confirmation, a security notice — cannot be switched off while you are using it.

7. How long information is kept

• Clinics keep patient and health records for as long as needed to provide care and to meet medical record-keeping and legal requirements.
• Patient portal conversations follow the clinic's patient-record retention

policy. Completing or cancelling an appointment does not delete the thread.

• Account and billing records are kept for as long as the account is active and as required afterward for legal and accounting purposes.
• Pharmacy counter sales are kept as part of the clinic's accounting and medical-supply records, on the same footing as its other billing records (section 2.4). A sale recorded with no name identifies nobody to begin with.
• System logs and security records are kept for a limited period and then removed by a scheduled job.
• An incomplete file upload — one interrupted by a closed browser tab, a lost connection, or anything else that stops it before it finishes — is removed automatically within hours. It is never added to a patient's record, whether or not it is ever completed, and it is not included when a clinic requests an export of its data (section 5.1).
• The record of who opened a patient's record (section 5) is kept for 2 years, then removed.
• The audit trail of changes to records is kept for 7 years, which is the period an investigation or a claim is most likely to reach back for.

7.1 How deletion actually works

When a deletion request is approved (see section 8), the records are not destroyed on the spot. Three things happen, in order:

1. Immediately. The records stop being visible in the system. Staff can no longer find or open them.
2. For the next 30 days. Nothing has been destroyed yet. The deletion can still be reversed, because deletions raised in error are a real risk and a window to catch them is worth more than speed.
3. After 30 days. The information is permanently removed. This step cannot be undone.

Before anything is hidden, a copy of the records is packaged into a single archive file so the clinic — or the company that asked, where applicable — has what was held. See section 5 for how that copy is protected.

What is permanently removed for a patient: name, contact details, date of birth, address, insurance details, patient portal messages, and the clinical record itself, including consultations, diagnoses, prescriptions, laboratory results, imaging studies with their image files, and uploaded documents.

What is deliberately kept: the billing history, de-identified as described in section 2.4. The clinic's accounts continue to balance, and the entries no longer identify anyone.

Verification records (section 2.7) are also kept, for the same reason. A certificate a patient handed to an employer stays checkable after the patient's records are deleted — otherwise deleting a record would silently turn every document ever issued from it into an apparent forgery. These records never contained the patient's full name or any health information to begin with. A clinic that wants a specific document to stop verifying can revoke it.

7.2 Closing a doctor's or staff member's account

When a clinician's or staff member's account is closed, their ability to sign in is destroyed: the password and the email address on the account are replaced with unusable values, every active session is ended, and the account cannot be used again. Releasing the original email address means the same person can register again later if they return.

Their name is kept on the records they authored. A prescription, a medical certificate or a consultation note names the clinician who issued it, and those are medical records — a document nobody appears to have signed is worse for the patient than one naming someone who has since left. Personal contact details on the account are removed.

7.3 Closing a clinic

When a clinic closes its account, the clinic is archived and immediately stops being reachable — no one can sign in and its public pages stop working. Its database is kept, unopened, for the same 30-day window, and is then permanently destroyed along with the keys that protect it. After that point the clinic's data cannot be recovered by anyone, including the platform operator.

The verification records for documents that clinic issued (section 2.7) are kept, and their codes continue to confirm that the closed clinic issued those documents. A certificate someone is still holding does not become unverifiable because the clinic has since shut down. These records hold the clinic's name as it was, no patient name and no health information.

8. Your rights

These are your rights under sections 16 to 18 of the Data Privacy Act of 2012. They are not conditional on where you live, and nothing in this policy or in the Terms of Use takes them away.

• To be informed — that a clinic or the operator holds information about you, and why, before it is collected or before it is used for something new. This policy is how that is done.
• To access — a copy of the information held about you, together with the purposes it is used for, who it has been or may be disclosed to, how it was obtained, how long it is kept, and the identity of the people responsible for it.
• To object — to processing based on consent or on legitimate interests, including to direct marketing (which we do not do) and to automated decision-making (which the platform does not perform).
• To correct — inaccurate or out-of-date information, and to have the corrected version passed on to anyone it was disclosed to.
• To erasure or blocking — to have information removed or withdrawn from the system where it is incomplete, outdated, false, unlawfully obtained, no longer necessary, or where you withdraw the consent it rested on. This right is subject to the record-keeping limits in section 8.1.
• To damages — compensation for damage suffered because of inaccurate, incomplete, outdated, false or unlawfully obtained information about you.
• To data portability (section 18) — where information about you is processed by electronic means and on your consent or on a contract, to obtain a copy in an electronic format that is structured and commonly used, so you can move it elsewhere.
• To complain — to lodge a complaint with the National Privacy Commission (privacy.gov.ph), whether or not you have raised it with us first.

If you die or become incapacitated, section 17 of the Act passes these rights to your lawful heirs and assigns, who may invoke them on your behalf.

How to exercise them

• Patients: contact the clinic where you are seen. The clinic is the Personal Information Controller for your record and decides these requests. If a request reaches us instead, we pass it to your clinic rather than answering it ourselves. Each clinic designates its own Data Protection Officer, whose name and contact details appear on the clinic's page in the public directory — that is the person to raise a privacy question or complaint with, because the operator's officer answers for the platform and cannot answer for a clinic's own decisions. A clinic that has not yet published one shows no such contact; ask the clinic directly, and you can go to the National Privacy Commission whether or not you have raised it with anyone first.
• Pharmacy counter customers who are not patients: contact the clinic you bought from. It holds the record and decides the request, exactly as it would for a patient — quote the tracking number on your receipt, which is how the clinic finds the sale. Its Data Protection Officer is listed on its page in the public directory.
• Staff, account holders, employer-portal users and public-portal visitors: contact the platform operator through the contact form on the public portal or at [email protected], which is the operator's contact point for data protection matters.

We respond within 15 working days, or tell you within that time why more is needed and when to expect an answer. There is no charge for a reasonable request; a request that is manifestly repetitive may attract a reasonable fee, and we will tell you before any fee applies.

Every request is written down. Each clinic has a register in the platform recording what was asked, the date it was received, the date the answer is due, whether the person asking was identified, and what was actually done about it. The deadline is counted in working days from the day the request arrived rather than the day it was written down, so a request that sat unread does not quietly gain a week. A refusal is recorded with its ground; a request answered is recorded with what was handed over, corrected or stopped. Ask your clinic what its register says about your request — that is what it is for.

Getting a copy is not a special request. Your clinic can produce your whole record in two forms, at any time: a PDF you can read, print or hand to another doctor, and a data file another clinic's system can import — which is the "structured, commonly used and electronically readable format" section 18 asks for. Both contain your details, consultations, prescriptions, released laboratory results, appointments, certificates issued and billing. Imaging is a separate request. Image files are large and are not packaged into the record export; a signed radiology report can be downloaded as a PDF from the study itself, and your clinic can provide the images on request. If your clinic has sent you a secure portal link, you can also see all of it yourself and download either form without asking anyone, at Your records in the portal.

Two limits are worth knowing in advance. Notes a clinician wrote for their own working use are not included in that copy — a record a doctor cannot write candidly in is a worse record for you, and the Act allows those to be withheld where releasing them would defeat the purpose the record is kept for. You can still ask for them to be considered for release, and your clinic must answer within 15 working days. And a request to erase a medical record can be refused, for the reasons in section 8.1.

8.1 Asking for your records to be deleted

Deletion is a reviewed process, not a button. Nobody can erase records unilaterally:

1. You ask your clinic. The clinic raises the request on your behalf and records the reason.
2. Someone else reviews it. For requests a clinic raises, the platform operator reviews and carries them out — a second pair of eyes on a clinic deleting its own records. For requests an employer or insurer raises (see below), the clinic reviews them.
3. There is a recovery period. As described in section 7.1, approved deletions stay reversible for 30 days before becoming permanent.

Two limits are worth stating plainly, because they are exceptions to "delete everything":

• Billing records are kept, de-identified. See section 2.4.
• A deletion may be declined. Medical record-keeping obligations, or an open matter such as an unsettled bill or a claim, can require a clinic to hold a record for longer. If a request is declined you are told the reason.

8.2 If your employer or insurer asks on your behalf

If you are linked to a company or HMO that uses the platform's employer portal — for example through a company-paid check-up — that company can ask a clinic to delete your records at that clinic.

The company can only ask. The clinic decides, because the clinic holds the medical record. A company's request covers your record at that one clinic; if you are a patient at other clinics, those records are separate and unaffected. A company can never raise a request about someone it is not linked to, and if the link between you and the company ends before the clinic decides, the request is withdrawn rather than carried out.

A company deleting its own account does not delete your clinical records. Those belong to the clinics that created them.

9. Children's information

The platform is used by clinics that may provide care to children. Any information about a minor is recorded and handled by the clinic as part of the child's medical record, under the responsibility of the clinic and the child's parent or guardian.

10. Changes to this policy

We may update this Privacy Policy from time to time. When we make significant changes, we will update the date at the top of this page and, where appropriate, provide additional notice.

11. Contact us

For questions about this policy or about how your information is handled:

• Patients: please contact the clinic where you are seen.
• Everyone else: please use the contact form on the public portal, or reach out to the platform operator at [email protected], which is the operator's contact point for data protection matters.

You may also complain to the National Privacy Commission at privacy.gov.ph, at any time, whether or not you have raised the matter with us first.

12. Compliance with Philippine law

This platform is built for clinics in the Philippines, so the standard it is measured against is the Data Privacy Act of 2012 (RA 10173) with its Implementing Rules and Regulations, the issuances of the National Privacy Commission, and Joint Administrative Order No. 2016-0002 of the Department of Health, PhilHealth and the DOST — the privacy guidelines for the Philippine Health Information Exchange, commonly called the Health Privacy Code.

12.1 What these documents and the platform address

• RA 10173 §11 — transparency, legitimate purpose, proportionality. Sections 2 and 3 state what is collected and why. The platform collects only what a clinic needs to provide care, and health information is deliberately excluded from system logs and error reports.
• §12 and §13 — a lawful basis, including the narrow grounds that permit health information at all. Section 3.1.
• §16(a) — the right to be informed. This policy, shown before a booking or a sign-up and accepted with a recorded timestamp (section 2.5).
• §16(b) to (e) — access, object, correct, erase or block. Section 8. Erasure runs as the reviewed workflow in sections 7.1 and 8.1, with a recovery window rather than an immediate destruction.
• §16(f) — damages, and §17 — transmissibility to your heirs. Section 8.
• §18 — data portability. Section 8, subject to the limit stated there and in section 12.2.
• §20(a) to (c) — organisational, physical and technical security. Section 5: role-based access; two-factor sign-in, always for the administration area and available to every clinic account with recovery codes; encryption keys unique to each clinic; encryption of both identity and health fields at rest; HTTPS in transit; enforced isolation between clinics; sign-in throttling; minimised logging; and an audit trail that is cryptographically chained so alteration is detectable, with the limits of that stated in section 5.
• §20(f) and NPC Circular 16-03 — breach notification. Section 5.4, and Terms of Use section 6.2.
• §21 — accountability, including for data handled by third parties. Section 6 names every sub-processor; Terms of Use sections 6.7 and 6.11 keep the operator answerable for what they do.
• IRR Rule X — the outsourcing agreement between a controller and its processor. Terms of Use sections 6.3 to 6.11 are that agreement, so no clinic has to negotiate one separately.
• JAO 2016-0002 — an audit trail of access to health information. Section 5: who opened which part of which patient's record, and when, reviewable by the clinic and retained for a stated period.
• JAO 2016-0002 — confidentiality of health information, access confined to those providing care, secure retention and disposal, breach management, and a patient's access to their own information. Sections 5, 6, 7 and 8. The employer and HMO portal is confined to a defined set of fields and never exposes a clinic's private clinical notes (section 6, and Terms of Use section 12.4).

12.2 What is not yet in place

A compliance claim is only as good as the parts it leaves out, so these are stated rather than omitted. Each is being worked on, and this section will shrink as they land.

• The operator has not yet formally designated and registered a Data Protection Officer with the National Privacy Commission, nor registered its data processing system under NPC Circular 17-01. Until it does, [email protected] is the contact point for data protection matters, and it is answered.
• The hosting jurisdiction is not stated in these documents. It is disclosed to any clinic on request (Terms section 6.11), but a data processing agreement should name it, and it will be named here.
• A privacy impact assessment has not been published.

If any of these matters to a decision you are making about the platform, ask us where it stands rather than assuming — [email protected].