Data Processing Addendum

Product: Caresoft eICU • Version: [v1.0] • Effective: 01/04/2026

This Data Processing Addendum ("DPA") forms part of the Master Services Agreement (the "Agreement") between Caresoft Systems Private Limited ("Processor", "Caresoft") and the hospital or healthcare organisation identified in the Order ("Controller", "Hospital"), and governs the processing of Personal Data, including health data, through the Caresoft eICU platform.

All Personal Data processed under this DPA is health data relating to critically ill patients. It is sensitive in every legal framework that applies to it, and a breach can cause serious and irreversible harm to identifiable individuals who are not in a position to protect themselves.

Both parties will treat it accordingly. Where this DPA is stricter than the law requires, the stricter standard applies.

Where this DPA conflicts with the Agreement, this DPA prevails on data protection. Where either conflicts with the Intended Use & Clinical Safety Statement on a question of clinical safety, that statement prevails.

1. Definitions

"Applicable Law" — the Digital Personal Data Protection Act, 2023 and rules; the Information Technology Act, 2000 and the SPDI Rules, 2011; CERT-In directions; applicable medical-records, clinical establishment and accreditation requirements; and, where relevant, the EU/UK GDPR.
"Patient Data" — Personal Data relating to the Hospital's patients processed through the Platform, including demographics, identifiers, admission and encounter data, device-derived physiological data, derived scores, clinical notes and documentation.
"Data Fiduciary" / "Controller", "Data Processor", "Data Principal" / "Data Subject", "Personal Data Breach" — as defined in Applicable Law. Under the DPDP Act, Controller means Data Fiduciary and Data Subject means Data Principal.
"Sub-processor" — a third party engaged by Caresoft to process Patient Data.

2. Roles

Data	Hospital	Caresoft
Patient Data in the Platform	Data Fiduciary / Controller	Data Processor
Device-derived physiological data	Controller	Processor
Clinical user accounts and access logs	Controller	Processor
Hospital's own account, billing and contract records	Counterparty	Controller
Aggregated, irreversibly de-identified operational metrics	—	Controller (subject to §17)

The Hospital determines the purposes and means of processing Patient Data. Caresoft has no independent purpose for it and acquires no rights in it.

Significant Data Fiduciary. A hospital processing health data at volume may be notified as a Significant Data Fiduciary under the DPDP Act, attracting additional obligations including a Data Protection Officer, independent audit and periodic impact assessment. Determining this is the Hospital's responsibility; Caresoft will provide the information reasonably required to support those obligations.

3. Scope and instructions

Caresoft processes Patient Data only on the Hospital's documented instructions. The Agreement, this DPA, the Hospital's configuration of the Platform, and its support requests constitute the complete instructions.
Caresoft will inform the Hospital if, in its opinion, an instruction infringes Applicable Law, and may decline to act on an instruction that would.
Processing required by law to which Caresoft is subject is permitted; Caresoft will inform the Hospital first unless legally prohibited. See §13 and §15.
Details of processing are in Annex I.

4. Hospital obligations

Establish and maintain a lawful basis for processing Patient Data, including for remote monitoring and for any transfer to a command centre operated by or for it.
Give patients the notices required by Applicable Law and obtain any required consent, including consent for tele-ICU observation where the law or its accreditation standards require it.
Determine and configure retention consistent with its medical-record obligations, and instruct Caresoft accordingly (§16).
Control user access — provision, review at least [quarterly], and revoke promptly on role change or exit. Caresoft cannot know when a clinician leaves the Hospital's employment.
Ensure clinical users are trained on confidentiality and on the correct handling of exports, screenshots and notifications containing patient identifiers.
Not place in the Platform any Personal Data outside the categories in Annex I without written agreement.
Handle Data Principal requests as Controller (§11).
Notify Caresoft immediately of any incident on the Hospital side affecting Patient Data or the Platform (§12, §13).

5. Caresoft obligations

Caresoft will: process only on instruction; ensure personnel are bound by confidentiality (§7); implement and maintain the measures in Annex II; engage Sub-processors only under §9; assist the Hospital under §10–§12; make available the information and access in §14; and return or delete Patient Data under §16.

6. Access to patient data

Caresoft personnel access Patient Data only where necessary to: resolve a support request raised by the Hospital; investigate a Patient Safety Incident or a security incident; perform contracted managed services; or comply with valid legal process.

Access is on a least-privilege, minimum-necessary basis, individually authenticated, never through shared accounts, and requires multi-factor authentication.
Every access to Patient Data by Caresoft personnel is logged with identity, timestamp, patient or record accessed, and stated reason. The log is available to the Hospital on request and is included in the audit trail.
Caresoft will notify the Hospital of access made for reasons other than a Hospital-raised ticket, unless legally prohibited.
Production Patient Data must not be copied into development, test, training or demonstration environments. Non-production environments use synthetic or irreversibly anonymised data only.
Patient identifiers are masked in notification channels, delivery logs, support tooling and monitoring wherever technically possible. Notifications are designed to convey that attention is required without disclosing clinical detail through insecure channels.
Caresoft personnel must not download, export, photograph or retain Patient Data on personal devices or personal accounts.

7. Personnel

All personnel with potential access to Patient Data are bound by written confidentiality obligations surviving employment, subject to background verification appropriate to the role, and trained on health data handling at induction and at least [annually].
Access is provisioned by role, reviewed at least [quarterly], and revoked within [24] hours of role change or exit.
Caresoft maintains a current list of roles with access to Patient Data and provides it to the Hospital on request.

8. Security measures

Caresoft implements and maintains the measures in Annex II, appropriate to the sensitivity of health data. Measures may be updated provided the overall level of security is not reduced; material changes are notified to the Hospital. Reduction of any measure in Annex II requires the Hospital's written agreement.

Security responsibility is shared as set out in the Agreement §10 and the Device Interfacing Policy. The Hospital is responsible for its network, device segment, edge agent physical security, endpoints and user access hygiene.

9. Sub-processors

Sub-processing of health data is deliberately minimised. Caresoft does not engage sub-processors for Patient Data beyond those in Annex III, and will not engage a sub-processor located outside India for Patient Data without the Hospital's prior written consent.

Each Sub-processor is engaged under a written contract imposing obligations materially equivalent to this DPA, including the access, logging and localisation requirements.
Caresoft remains fully liable to the Hospital for its Sub-processors' acts and omissions.
Notice. At least [30] days before a new Sub-processor begins processing Patient Data, by written notice to the Hospital's named data protection contact.
Objection. The Hospital may object within [15] days on reasonable data protection grounds. Caresoft will propose an alternative; if none is agreed within [30] days, the Hospital may terminate the affected scope without penalty with a pro-rata refund and the transition support in Agreement §23.
Third-party notification channels (email, SMS, WhatsApp providers) receive only masked or minimal content and are listed in Annex III with the data they receive.

10. Data location and transfers

Patient Data is stored and processed within India, including primary storage, backups and disaster recovery copies.
Caresoft support and engineering access is from India. Remote access from outside India is not permitted for Patient Data without the Hospital's prior written consent.
Transfers outside India are made only where permitted under Section 16 of the DPDP Act and any Central Government restriction, and only with the Hospital's written instruction.
Where the Hospital is subject to a stricter localisation requirement — sectoral, accreditation or contractual — it must notify Caresoft in writing and Caresoft will confirm whether the deployment satisfies it.
Where the GDPR applies to any processing, the Standard Contractual Clauses (Module Two, or Module Three where the Hospital is itself a processor) are incorporated, with Annex I and Annex II of this DPA populating the corresponding SCC annexes; governing law [Ireland]; Clause 9 option 2 with [30] days' notice; Clause 11 optional redress body does not apply.

11. Data principal rights

The Hospital, as Data Fiduciary, is responsible for responding to patient requests for access, correction, erasure, nomination or grievance redressal.
The Platform provides the Hospital with the means to locate, export and amend Patient Data directly. Amendments are recorded as amendments with author, timestamp and reason; original entries are preserved as required for a medical record.
If Caresoft receives a request directly from a patient, it will not respond substantively, will refer them to the Hospital, and will inform the Hospital within [2] working days.
Caresoft will assist with requests the Hospital cannot fulfil through the Platform, at cost where the assistance is more than trivial.
Erasure is constrained. Clinical records are subject to medical-record retention obligations, and audit trails are immutable by design for patient safety and evidential reasons. Caresoft will implement erasure only on the Hospital's written instruction, and will identify what cannot lawfully or safely be erased.

12. Breach notification

Caresoft will notify the Hospital of any Personal Data Breach affecting Patient Data without undue delay and in any event within [6] hours of becoming aware.

Six hours, not 48 — because the Hospital may itself be required to report onward within a short statutory window, and because CERT-In's own deadline runs from awareness.

Initial notification is by phone to the Hospital's named contact and in writing, and includes what is known at the time. Information is supplemented as the investigation proceeds.
Notification will describe: the nature of the breach; categories and approximate number of patients and records affected; likely consequences; measures taken and proposed; and a named contact.
Caresoft preserves all evidence and will not alter or delete logs relating to the breach until the investigation is closed.
The Hospital is responsible for notifying the Data Protection Board of India, any other regulator, its accreditation body, and affected patients. Caresoft will provide the information and support needed and will not communicate with affected patients without the Hospital's written instruction.
Caresoft provides a written root cause analysis with corrective and preventive actions within [10] working days.
Notification is not an admission of fault or liability.
The Hospital must notify Caresoft within [6] hours of any breach on its side affecting Patient Data or capable of affecting the Platform or other hospitals.

13. Mandatory reporting and retention

Caresoft is required to report specified cyber incidents to CERT-In within 6 hours of becoming aware, and maintains ICT system logs for a minimum of 180 days within India, producible to a lawful authority on demand.
System clocks are synchronised to NPL or NIC time servers.
These obligations override conflicting instructions, including an erasure instruction, to the extent the law requires. Caresoft will tell the Hospital which obligation applies and what is being retained.
Where a CERT-In report concerns an incident affecting the Hospital's data, Caresoft will inform the Hospital that a report has been made, unless prohibited.

14. Audit rights

Audit rights here are broader than in a general SaaS agreement, because the Hospital carries non-delegable accountability for patient data and is itself subject to inspection.

On request, Caresoft provides: its security documentation and completed due-diligence questionnaire; penetration test and vulnerability assessment summaries; access logs relating to the Hospital's data; restore test and DR exercise evidence; the current Sub-processor list; and any certification reports it holds.
The Hospital may audit Caresoft's processing of Patient Data once per twelve months, and additionally after a Personal Data Breach or Patient Safety Incident, or where required by a regulator or accreditation body.
Audits require [30] days' notice (or less following an incident or on regulatory direction), are conducted during business hours, are subject to confidentiality, and must not access other hospitals' data.
The Hospital may use an independent auditor who is not a competitor of Caresoft and who signs a confidentiality undertaking.
The Hospital bears its own audit costs; Caresoft bears its own participation costs for the annual audit and for any audit following a breach attributable to Caresoft.
Caresoft will cooperate with any inspection or request from a regulator or accreditation body directed at the Hospital and relating to the Platform.

15. Government access

If Caresoft receives a legally binding request from a public authority for Patient Data, it will assess validity, challenge it where there are reasonable grounds, disclose only the minimum required, and notify the Hospital promptly unless legally prohibited — in which case Caresoft will seek a waiver and notify as soon as the prohibition lapses. Where feasible, Caresoft will direct the authority to the Hospital as Data Fiduciary. Caresoft maintains records of such requests to the extent lawful.

16. Retention, return and deletion

The Hospital specifies the retention period for Patient Data in writing, consistent with its medical-record obligations. Caresoft configures the Platform accordingly and does not delete Patient Data on its own initiative.
Where no instruction is given, Caresoft retains for the default period in the Order and seeks written instruction before any deletion.
During the term and for [30] days after termination, Caresoft will export all Patient Data and the associated audit trail in a documented, machine-readable format.
After the export period and on the Hospital's written confirmation, Caresoft deletes Patient Data from production and, on the backup rotation cycle, from backups within [35] days, and certifies deletion in writing.
Deletion is subject to §13 and to records Caresoft must retain as Controller. Retained copies remain subject to this DPA and are processed only for the purpose requiring retention.
Data relating to an open Patient Safety Incident or investigation is preserved until closure regardless of any deletion instruction.

17. Secondary use and artificial intelligence

Caresoft will not: use Patient Data for its own purposes; sell, licence or share it; use it for marketing or research; or use it to train, fine-tune, evaluate or improve any artificial intelligence or machine learning model — whether Caresoft's own or a third party's.

Aggregated operational metrics (bed counts, uptime, throughput, error rates) may be used by Caresoft for capacity planning and product improvement only where irreversibly de-identified such that no patient, clinician or hospital can be identified or re-identified.
Any proposal to use Patient Data for research, benchmarking, publication or model development requires a separate written agreement, the Hospital's ethics committee approval where applicable, and any consent required by law. It is outside this DPA.
Where a Platform feature uses a third-party AI service, Caresoft will disclose it in advance, and no Patient Data will be sent to such a service without the Hospital's prior written consent.

18. Liability

Liability under this DPA is subject to the Agreement §20, save that the cap in §20.2 does not apply to breach of data protection obligations, as stated in §20.3. Caps apply in the aggregate across the Agreement and this DPA. Nothing limits liability that cannot lawfully be limited, or a Data Principal's rights.

19. Term and general

This DPA takes effect with the Agreement and continues while Caresoft processes Patient Data.
It may be updated where required by a change in Applicable Law or a regulatory decision, on [30] days' notice; changes reducing protection require the Hospital's written agreement.
Order of precedence: Intended Use Statement (clinical safety) → SCCs where applicable → this DPA → the Agreement → other policies.
Governed by the law of the Agreement.
Data protection contacts — Hospital: [name, role, email, phone]. Caresoft: [email protected], Grievance Officer Rajeev Pillai

Annex I — Details of processing

Item	Detail
Subject matter	Acquisition, transmission, storage, display, trending, scoring, notification and documentation of critical care patient data through the Caresoft eICU platform.
Duration	Term of the Agreement, plus retention and deletion periods under §16 and mandatory retention under §13.
Nature and purpose	Supporting remote observation, clinical documentation, handover, review, reporting and audit of critically ill patients. Adjunct to bedside care; not diagnosis or treatment.
Categories of Data Principals	Patients admitted to the Hospital's critical care areas; clinical and administrative users of the Platform.
Categories of Personal Data	Patient identifiers (name, MRN, hospital composite key, age, sex); admission, discharge and transfer data; bed and encounter identifiers; device-derived physiological measurements; derived scores including early warning scores; clinical notes, observations and documentation entered by users; alert and escalation records; user account, role and access-log data.
Special / sensitive categories	Yes — health data throughout. Processed under the additional safeguards in this DPA and Annex II. No other special category is processed.
Frequency	Continuous while the Platform is in clinical use.
Retention	As instructed by the Hospital, consistent with medical-record obligations. See §16.
Sub-processor processing	Hosting and storage within India; notification delivery with masked content. See Annex III.

Annex II — Technical and organisational measures

Area	Measures
Encryption	TLS 1.2+ in transit for all traffic including device ingest; encryption at rest for databases, backups and exports; HMAC-signed device batches with rejection and logging of invalid signatures; secrets and keys stored encrypted with restricted retrieval; per-install password pepper in addition to per-user salt.
Access control	Role-based access with 11 roles and granular permissions; portal separation enforced server-side with wrong-portal attempts audited; MFA for administrative access; least privilege; no shared accounts; access reviewed [quarterly]; revocation within [24] hours of exit.
Audit	Immutable audit trail of authentication, data access, clinical entries, amendments, configuration changes and exports, with identity, timestamp and reason. Clinical entries are amended, never overwritten. Audit records available to the Hospital.
Data integrity	Idempotent batch identifiers preventing duplication on replay; store-and-forward buffering at the edge; quarantine rather than discard for unattributable samples; closed-interval patient–device association; clock offset measurement and flagging; data gap recording and surfacing.
Segregation	Multi-tenant isolation enforced at the data layer; production separated from development, test and training; no production Patient Data in non-production environments.
Minimisation in channels	Patient identifiers masked in notifications, delivery logs, monitoring and support tooling; notification content designed to prompt attention without disclosing clinical detail over third-party channels.
Availability	Backup per SLA §11 with stated RPO and RTO; encrypted backups held in India in a separate failure domain; restore testing [quarterly]; DR exercise [annually]; edge buffering protecting device data during platform outage.
Vulnerability management	Regular patching; dependency and vulnerability scanning; penetration testing [annually] with summary available to the Hospital; documented remediation timelines by severity.
Secure development	Peer-reviewed changes; version control; separated environments; release and rollback procedures; defect tracking; documented testing before release, including runtime verification of the full ingest-to-alert pipeline.
Logging and monitoring	Authentication, ingest, error and integrity telemetry; watchdog on device heartbeats; ICT system logs retained ≥180 days in India; alerting on anomalous access patterns.
Incident response	Documented plan with defined severities including a patient-safety severity above critical; 24×7 on-call; notification to the Hospital within [6] hours; CERT-In within 6 hours; evidence preservation; root cause analysis within [10] working days; field safety notices where multiple sites are affected.
Personnel	Background verification; confidentiality agreements surviving employment; health data handling training at induction and [annually]; documented joiner-mover-leaver process.
Physical	Hosting in access-controlled facilities within India under the certifications in Annex III; restricted physical access to any Caresoft-managed hardware.
Deletion	Secure deletion on instruction with written certification; backup expiry within [35] days; secure wipe of decommissioned media by the hosting provider under its certified procedures.

Annex III — Sub-processors

Current as at the version date. Additions are notified under §9.

Sub-processor	Purpose	Patient Data accessed	Location	Certifications
[Hosting / cloud provider]	Application and database hosting, backup storage	All Patient Data, encrypted at rest	India — [region]	[ISO 27001, SOC 2, etc.]
[Transactional email provider]	Notification and report delivery	Recipient address; masked patient reference only	[region]	[certifications]
[WhatsApp / SMS provider]	Notification delivery where enabled	Recipient number; masked patient reference only	[region]	[certifications]
[Monitoring / error tracking]	Platform health and error diagnostics	Technical metadata; no Patient Data	[region]	[certifications]
[Helpdesk, if used]	Support ticketing	Only what the Hospital includes in a ticket	[region]	[certifications]

Where a notification channel provider is located outside India, only masked content is transmitted and no clinical detail leaves the country. If the Hospital requires that no data whatsoever traverse a non-Indian provider, notification channels must be configured accordingly — record this in the Order.