Data Processing Agreement

What this document is. When your hospital uses Medora, you decide what patient data is collected and why — you are the controller. We only hold and process it to run the service for you — we are the processor. This agreement sets out what we must and must not do with it.

1. Parties and roles

This Data Processing Agreement ("DPA") is between:

Customer — the healthcare organisation named on the order form, acting as controller; and
[LEGAL ENTITY NAME] trading as Medora, acting as processor.

It forms part of the Terms of Service. Where they conflict on data protection, this DPA prevails.

2. Scope

This DPA applies to personal data that we process on your behalf when you use Medora — principally patient records, and the staff account data you enter. Details are in Annex A.

It does not cover data for which we are the controller — our billing records, our own marketing contacts — which is dealt with in the Privacy Policy.

3. Processing on your instructions

We process personal data only on your documented instructions. Using the service as intended constitutes those instructions.
If we believe an instruction breaches applicable data protection law, we will tell you and may pause that processing.
If law compels us to process beyond your instructions, we will notify you first unless that law forbids it.
We will not sell your data, use it for advertising, or use it to train machine learning models.

4. Our people

Everyone with access is bound by written confidentiality obligations that survive their employment.
Access is granted on a least-privilege basis and reviewed at least [quarterly].
Support staff access customer environments only when you request help, for as long as needed, and it is logged.
Staff receive data protection and security training at induction and at least annually.

5. Security measures

We implement appropriate technical and organisational measures, described in Annex B. We may update them provided the level of protection is not reduced.

6. Sub-processors

You give general authorisation for us to engage the sub-processors in Annex C.
We give at least [30] days notice before adding or replacing one that handles patient data.
You may object on reasonable data protection grounds within that period. If we cannot resolve it, you may terminate the affected service without penalty and receive a pro-rata refund.
Each sub-processor is bound by obligations no less protective than these, and we remain fully liable for their performance.

7. Data subject rights

The service lets you access, correct, export and delete records directly, which will usually be enough to answer a request yourself.

Where it is not, we will assist you, taking into account the nature of the processing. If a patient contacts us directly we will not respond substantively — we will refer them to you and tell you within [5] working days.

8. Personal data breach

We will notify you without undue delay, and in any event within [48] hours of becoming aware of a personal data breach affecting your data.
The notification will describe the nature of the breach, the categories and approximate number of records affected, the likely consequences, and the measures taken or proposed.
Where we cannot provide everything at once, we will provide it in phases without undue further delay.
We will not make public statements identifying you without your consent unless legally required.
Notifying regulators and affected individuals is your responsibility as controller; we will give you the information you need to do it.

9. Assessments and audits

We will give you reasonable assistance with data protection impact assessments and prior consultations.
We will make available the information needed to demonstrate compliance with this DPA.
You may audit once per year on [30] days notice, or more often after a breach or regulator request. Audits happen in business hours, must not disrupt the service, and are subject to confidentiality.
Where available, current third-party reports or certifications may be provided to satisfy an audit request.

10. International transfers

We will not transfer personal data outside the country of origin unless an appropriate safeguard is in place — an adequacy decision, Standard Contractual Clauses, or the equivalent local mechanism. Where SCCs apply they are incorporated by reference and this DPA populates their appendices.

Data residency options are listed in Annex A. If your law requires local storage, agree it with us in writing before deployment.

11. Return and deletion

You may export your data at any time during the term, in an open, machine-readable format.
On termination we keep it for [30] days so you can export, then delete it from live systems.
Backup copies are purged within the normal backup cycle, no later than [35] days after live deletion.
We will certify deletion in writing on request.
We may retain data where law requires, for as long as it requires, and it stays protected by this DPA.

Note on clinical retention. Medical records are usually subject to statutory retention periods far longer than a software subscription — often years or decades. Meeting those is your obligation as controller. Export before you terminate.

12. Liability

Liability under this DPA is subject to the limitations in the Terms of Service, except where applicable data protection law does not permit that limitation.

Annex A — Details of processing

Subject matter	Provision of hospital management software
Duration	The subscription term, plus the retention window in section 11
Nature and purpose	Storage, organisation, retrieval, display and export of health and administrative records, so the Customer can run its healthcare operations
Types of personal data	Names, contact details, dates of birth, gender, national or health identifiers, clinical notes, diagnoses, prescriptions, medication administration, test results, imaging reports, admission and discharge records, billing and payment records, insurance details, staff account and access records
Special category data	Yes — health data. This is the core of the service. May also include data revealing religion or ethnicity where a Customer records it
Categories of data subject	Patients and their next of kin; the Customer's employees, clinicians and contractors
Frequency	Continuous, for the duration of the subscription
Hosting locations	[PRIMARY REGION]; backups in [BACKUP REGION]. Residency available in [LIST] on request

Annex B — Technical and organisational measures

Access control

Role-based permissions inside the application; each user has an individual account
Passwords stored using industry-standard one-way hashing
Least-privilege administrative access, reviewed regularly
Session timeouts and forced re-authentication

Encryption

TLS for all data in transit
Encryption at rest for databases and backups

Isolation

Each Customer's data is logically separated; no pooling between customers
Separate credentials and separate configuration per workspace

Logging and accountability

Audit records for clinical and financial changes — user, action, record, timestamp, origin address
Authentication logging including failed attempts
Logs protected against unauthorised alteration

Resilience

Daily encrypted backups with periodic restore testing
Point-in-time recovery within the retention window
Documented incident response procedure

Organisational

Confidentiality obligations for all personnel
Security and data protection training
Change control and code review before release
Vendor assessment before engaging a sub-processor

Annex C — Approved sub-processors

Name	Purpose	Location
[HOSTING PROVIDER]	Application and database hosting	[REGION]
[BACKUP PROVIDER]	Encrypted offsite backup	[REGION]
[EMAIL PROVIDER]	Transactional email — appointment and system notifications	[REGION]
[PAYMENT PROVIDER]	Subscription billing — no patient data	[REGION]
[ERROR MONITORING]	Fault diagnosis — configured to exclude patient data	[REGION]

To be notified of changes, email [PRIVACY EMAIL] and ask to join the sub-processor notification list.

Need this signed? We will countersign a copy for your records — ask us. If you are a US covered entity, request a Business Associate Agreement as well; this DPA alone does not satisfy HIPAA.