Privacy Policy

Product: Screenify • Version: [1.1] • Effective: 01/04/2026

This policy explains how Caresoft Systems Private Limited ("Caresoft", "we") handles personal data in connection with Screenify, our hospital display management and media platform. It is written for hospitals using Screenify, staff who sign in to it, and patients and visitors who see the screens.

The short version for patients and visitors: the screens do not watch you.

Screenify has no cameras, no face detection, no footfall sensors and no mobile device tracking. We do not measure who is standing in front of a screen, how many people are there, how long they look, or anything about them at all. We record only what the screen itself displayed and when.

Contents

Who is responsible for what
What we deliberately do not collect
Queue and appointment information
What appears on a public screen
Staff and user data
Playback and utilisation data
Content and its subjects
Hospital account data
Website visitors
Why we process it
Who can see it
Where data is held
How long we keep it
Security
If something goes wrong
Rights
Contact and Grievance Officer
Changes

1. Who is responsible for what

Data	Hospital	Caresoft
Queue and appointment information displayed on screens	Data Fiduciary / Controller	Data Processor
The decision on what identifiers appear publicly	Controller — entirely the Hospital's	Provides the configuration and the safer default
Content the Hospital uploads or approves	Controller / publisher	Processor
Staff accounts and audit logs	Controller	Processor
Hospital's contract, billing and support records	Counterparty	Controller
Our website and enquiry forms	—	Controller

Processing terms between Caresoft and each hospital are in the Data Processing Addendum, which prevails for hospital customers.

2. What we deliberately do not collect

Digital out-of-home advertising has, in many markets, become an audience-measurement business. Screenify is not built that way, and in a hospital it should not be.

No cameras or image capture of any kind on any screen.
No face detection, face recognition, age or gender estimation, or any inference about anyone in view.
No footfall sensors, beacons, Wi-Fi probe capture or Bluetooth scanning.
No mobile device identifiers, MAC addresses or location data from anyone near a screen.
No linking of screen exposure to any individual, patient record, advertising profile or third-party dataset.

We will not introduce any audience-measurement technology without the hospital's prior written agreement and a separate privacy assessment. If a future feature would change what is stated in this section, it will be notified in advance, not slipped into a release note.

3. Queue and appointment information

To show a waiting area which token is being served, the Platform receives from the hospital's systems: token or appointment number, counter or consulting room, doctor or department, status, and — only where the hospital configures it — a patient name or partial identifier.

This information is received, held briefly to render the display, and retained only as long as needed for the display and for the hospital's own reporting. It is not used for any other purpose, is never combined with advertising, and is never shared with an advertiser.

4. What appears on a public screen

A screen in a corridor is a public disclosure. Showing a patient's full name next to a consulting room tells everyone present which specialist that person is seeing. In some departments that inference is sensitive enough to cause real harm.

Screenify defaults to token numbers and masked identifiers, because defaults are what most sites will run forever.
The hospital may configure what is displayed. Where it chooses to show names or other identifying information, that is the hospital's decision, on its own lawful basis and its own assessment of the setting.
The Platform supports token-only display, partial masking, and different settings for public corridors and restricted areas.
Clinical information is never displayed — no diagnosis, no investigation, no treatment detail, in any zone, in any configuration.
Hospitals should tell patients, in their own privacy notice or at registration, what will appear on public screens.

5. Staff and user data

For each user of the Platform: name, role, work email and phone, hospital and department, credentials (passwords stored only as salted and peppered one-way hashes), permissions, and a record of sign-ins and actions — including who scheduled or approved each item of content, which is how content approval is evidenced.

Where a screen operates under its own device or user login, that login identifies the screen, not a person watching it.

6. Playback and utilisation data

We record, per screen: what was scheduled, what was rendered, start and end times, duration, errors, and whether the screen was online. This is device-level proof of play.

Playback is not viewership. A proof-of-play record says a file was rendered on a display at a time. It says nothing about whether anyone was present or looking, and we make no claim that it does. Advertisers receive playback evidence, never audience data — because we do not have any.

7. Content and its subjects

Content uploaded by a hospital or an advertiser may contain personal data — a doctor's photograph and name, a staff member in a video, a person in a stock image. The party supplying the content is responsible for holding the necessary rights and consents.

No identifiable patient may appear in content without written consent, and that consent is the hospital's or advertiser's responsibility to obtain and retain.

8. Hospital account data

Organisation name and address, registration and GSTIN details, named administrative and technical contacts, sites, screen counts, subscription and billing records, commercial terms and support correspondence. For this data Caresoft is the controller.

9. Website visitors

Enquiry form submissions, IP address, browser and device information, pages viewed and referrer. Strictly necessary cookies for session and security; analytics cookies only with consent.

The screens themselves set no cookies and collect nothing from anyone viewing them.

10. Why we process it

To render the display each screen is scheduled to show.
To show accurate queue and appointment information in waiting areas.
To let hospitals schedule, approve and manage content across their screen estate.
To monitor screen health and report utilisation, so a dark screen is noticed.
To produce proof-of-play evidence for the hospital and for advertising reconciliation.
To evidence who approved which content, which matters if a complaint is made.
To provide support and investigate faults.
To meet legal obligations, including mandatory log retention and incident reporting.
To administer and bill the hospital's account.

We do not use hospital or patient data for our own purposes, sell it, share it between hospitals, provide it to advertisers, or use it to train artificial intelligence models. This is a contractual commitment in the Data Processing Addendum.

11. Who can see it

Hospital users — as authorised by the hospital, limited by role. The hospital provisions and revokes its own users.
Caresoft personnel — only to run and support the service, investigate an incident, or comply with law. Access is individually authenticated, requires multi-factor authentication for administrative roles, and is logged with the person, time and reason. Production data is never copied into development, test or demonstration environments.
Advertisers — receive proof-of-play evidence for their own campaigns only. They receive no queue data, no patient data, and no audience data.
Sub-processors — a small disclosed set, listed in the DPA. Hosting is within India.
Authorities — where compelled by valid legal process. We assess each request, disclose the minimum required, and notify the hospital unless prohibited.

12. Where data is held

Platform data is stored and processed within India, including backups. Caresoft support and engineering access is from India. Transfers outside India occur only where permitted by law and instructed by the hospital in writing. Content may be cached locally on a screen for playback resilience; that cache sits on hospital premises under hospital control.

13. How long we keep it

Data	Retention
Queue and appointment information	Held for display and short-term reporting only — [30] days by default, configurable by the hospital
Playback and proof-of-play records	[24] months, or as required for advertising reconciliation
Content and approval records	For the term, plus [24] months — approval evidence may be needed if a complaint is made
Staff accounts and audit logs	For the term, plus [24] months
System logs required by law	Minimum 180 days, held in India
Backups	Rolling [35] days
Hospital account, contract and tax records	Up to 8 years as required by Indian tax law
Website enquiries	[24] months, or until removal is requested

Queue information has the shortest retention of anything here, deliberately. Once the patient has been seen, it has served its purpose. Hospitals needing longer retention for operational analysis should configure it consciously rather than by default.

14. Security

Measures include: encryption in transit and at rest; role-based access with multi-factor authentication for administrative roles; tenant isolation; device authentication for screens, so an unregistered display cannot join and pull content; audit logging of scheduling and approval actions; no production data in non-production environments; vulnerability scanning and periodic penetration testing; and a documented incident response plan.

Full measures are in the DPA. The hospital is responsible for its network, screen physical security, and user access hygiene — including revoking access when staff leave.

15. If something goes wrong

We notify the affected hospital of any personal data breach within [24] hours of becoming aware, and sooner where queue or patient data is involved.
We are required to report specified cyber incidents to CERT-In within 6 hours, and to retain system logs for a minimum of 180 days within India.
Evidence is preserved until the investigation closes.
The hospital notifies patients and regulators as data fiduciary. We provide the information and support required.
We provide a written root cause analysis with corrective actions within [10] working days.

16. Rights

16.1 Patients and visitors

If you are concerned about what appeared on a screen — your name shown when you did not expect it, or an advertisement you found inappropriate — raise it with the hospital. The hospital decides what its screens display and approves every item shown.

You may also contact our Grievance Officer (Section 17). Complaints about displayed content are acknowledged within 24 hours and actioned within the timelines prescribed by law.

We hold no profile of you, so there is generally nothing about you for us to give you, correct or delete. That is by design.

16.2 Hospital staff

Your account and activity data forms part of your hospital's record. Raise requests with your hospital administrator; we will assist them.

16.3 Hospitals and website visitors

Write to [email protected]. We verify identity and respond within 30 days. Requests conflicting with mandatory retention will be met in part, with reasons.

17. Contact and Grievance Officer

Security incidents: [email protected]

Grievance Officer (Information Technology Act, 2000; Digital Personal Data Protection Act, 2023)
Name: Rajeev Pillai
Email: [email protected]
Address: 311, Mahesh Industrial Estate , Silver Park, Mira Road East , Thane -401107
Acknowledgement within 24 hours; resolution within 15 days.

You may complain to the Data Protection Board of India if you are dissatisfied with our response.

Caresoft Systems Private Limited, Registered office address: 311, Mahesh Industrial Estate , Silver Park, Mira Road East , Thane -401107, CIN: U72900MH2022PTC387875.

18. Changes

We may update this policy. The version date will change. Hospitals are notified of material changes at least [30] days in advance; changes reducing protection require the hospital's agreement under the DPA. Any change to Section 2 will be notified prominently and in advance.