Privacy Policy
A NABHDesk tenant ends up holding more sensitive material than most hospitals expect when they buy a "compliance tool" — patient grievances, incident reports naming staff, root cause analyses, employee credentialing and training records. This policy explains what happens to it.
NABHDesk is supplied by Caresoft Systems Private Limited ("Caresoft", "we"), Mumbai, India.
Four commitments:
1. Data is stored and processed within India.
2. We never share data between hospitals — not identifiably, not as an anonymised example, not as a benchmark.
3. We never sell it, and never use it for our own purposes.
4. We never use it to train artificial intelligence models.
- Who is responsible for what
- What is held
- Patient data in a compliance tool
- Employee data
- Anonymous feedback
- Who can see it
- Caresoft access
- No cross-hospital anything
- Why we process it
- What we never do
- Sharing and sub-processors
- Where data is held
- How long it is kept
- Destruction register
- Security
- If something goes wrong
- Legal process
- Rights
- Cookies
- Contact and Grievance Officer
1. Who is responsible for what
| Data | Hospital | Caresoft |
|---|---|---|
| Patient feedback and grievances | Data Fiduciary | Processor |
| Incident reports, RCAs, CAPAs | Data Fiduciary | Processor |
| Staff credentialing, training, competency | Data Fiduciary | Processor |
| Documents, minutes, indicators, audits | Controller | Processor |
| Hospital user accounts and audit logs | Controller | Processor |
| Subscription, billing, support and access requests | Counterparty | Controller |
| Website, enquiries and lead capture | — | Controller |
| System logs required by law | — | Controller |
2. What is held
Depending on which modules you use: assessment scores and evidence notes; controlled documents and their approval and acknowledgement history; committee membership, meeting minutes and action points; quality indicator values; incident reports, root cause analyses and corrective actions; audit and drill findings; staff credentialing, training and competency records; equipment, maintenance, calibration and licence records; patient feedback responses and grievance records; record retention and destruction entries; and user accounts with activity logs.
3. Patient data in a compliance tool
Hospitals routinely underestimate how much patient data ends up here.
A grievance names a patient. An incident report describes what happened to a specific person, often with a diagnosis and a date. An RCA reconstructs a clinical sequence. That is health data, and it is frequently health data about the hospital's worst day.
- Record what the investigation genuinely needs. An incident can usually be analysed with an identifier and clinical facts — the full name, address and phone number are rarely necessary for the RCA itself.
- Free-text fields are stored as typed. Staff will write more than they intend under pressure.
- Restrict who can open incidents and grievances. A quality committee needs them; a training coordinator does not.
- You are the Data Fiduciary and are responsible for the lawful basis, and for any notice a complainant or patient requires.
4. Employee data
- Credentialing, training and competency records are personal data about identifiable employees, and are often performance-relevant.
- Incident records may name staff involved. That is legitimate for investigation, and it is also the material of a disciplinary or a claim — handle access accordingly.
- Do not import more than the module needs. A staff extract often carries salary, identifiers and personal contact details the platform has no use for.
- Do not upload government identity numbers. The platform does not require them and they should not be here.
- Your obligations to your employees under employment law and the DPDP Act apply to what you record about them.
5. Anonymous feedback
Patient feedback is anonymous by default. A patient can give honest feedback without identifying themselves, which is the only way feedback is worth collecting.
- Where a poor score automatically opens a grievance, that grievance carries only what the patient chose to provide.
- A grievance from a contactable complainant cannot be closed without recording that they were told the outcome. That is a deliberate constraint — closing a complaint without telling the complainant is not closing it.
- Do not attempt to identify an anonymous respondent from timing, ward or free text. If your process depends on that, the feedback is not anonymous and should not be described as such.
- Aggregate analysis is fine. Re-identifying an individual respondent is not, and would be a breach of the basis on which they responded.
6. Who can see it
| Who | Access |
|---|---|
| Hospital users | Only the modules and records their permissions allow |
| Hospital administrator | Everything in your tenant, per your own governance |
| Assessor role | Read only, enforced server-side. Sees what you grant, including incidents unless restricted |
| Consultants you grant access to | What you grant, and nothing after you revoke it |
| Other hospitals on NABHDesk | Nothing. Tenant isolation at the data layer |
| NABH | No access. We have no relationship with them |
| Caresoft personnel | No routine access — see §7 |
Set module permissions deliberately at go-live. The default assumption that "quality staff see everything" is how a training coordinator ends up reading a grievance about a named consultant.
7. Caresoft access
Our personnel access hospital data only where:
- you raised a support request that requires it;
- a security incident is being investigated; or
- we are compelled by valid legal process (§17).
Every access is individually authenticated, requires multi-factor authentication, and is logged with the person, time, records accessed and stated reason. The log is available to you on request. Production data is never copied into development, test or demonstration environments — those use synthetic data only.
We do not read your incidents. Not for quality sampling, not to improve the product, not out of interest. If a support ticket requires us to look at an incident record, we will ask you first and say why.
8. No cross-hospital anything
We do not pool, compare, benchmark or aggregate data across hospitals — in any form, identifiable or otherwise.
No "average incident rate across our client base". No "hospitals like yours score X". No anonymised case studies drawn from your RCAs.
Comparative quality data would be commercially valuable and we are not building it. A hospital's incident rate, indicator values and readiness position are among the most sensitive things it holds, and a vendor quietly aggregating them is doing something the hospital did not agree to.
Product improvement uses aggregate operational metrics only — which screens are used, where errors occur, how long a page takes. Never content, never scores, never incidents.
9. Why we process it
- To operate the modules you use and store what your team records.
- To calculate readiness against the element library and your declared scope.
- To run workflow rules — auto-raised CAPAs, RCA tasks, overdue tracking, approval gates.
- To maintain audit trails of who did what.
- To receive values pushed from a connected HIS.
- To provide support you request.
- To secure the platform and investigate misuse.
- To meet legal obligations, including mandatory log retention and incident reporting.
10. What we never do
We do not:
• sell, rent or trade any data
• share data between hospitals in any form (§8)
• disclose your incidents, scores or readiness to NABH, an insurer, an empanelment body or anyone else
• use your data in marketing, case studies or demonstrations
• publish benchmarks in which a hospital could be identified or inferred
• use your data to train artificial intelligence models
• edit, backdate or remove a record to improve its appearance
That last one is a commitment about our own conduct: audit trails are immutable by design and no member of our team may be asked to alter one, by you or by anyone. A quality system whose history can be rewritten is worthless.
11. Sharing and sub-processors
| Who | Receives |
|---|---|
| Hosting provider (India) | Encrypted data at rest |
| Transactional email | Recipient address and message text — notifications, reset links |
| SMS / WhatsApp gateway, where you enable it | Number and message text |
| Payment gateway | Your payment details. Not hospital data |
| Authorities | Only where compelled (§17) |
Notification content should be minimal. A task reminder naming an incident and a patient is a disclosure to whoever holds that phone or inbox. Configure templates accordingly.
12. Where data is held
Hospital data, uploaded documents, backups and disaster recovery copies are stored and processed within India. Support and engineering access is from India. Uploaded files are stored outside the web root, not merely behind a configuration file.
13. How long it is kept
| Data | Retention |
|---|---|
| Quality records, assessments, indicators | As configured by you, subject to your statutory and accreditation obligations |
| Controlled documents, including obsoleted versions | Retained — superseded versions are obsoleted, not deleted |
| Incidents, RCAs, CAPAs | As configured; consider limitation periods before setting a short value |
| Grievances | As configured, subject to your grievance obligations |
| Staff records | As configured, subject to employment law |
| Audit trails of who did what | Life of the record |
| Account and user records | Life of the account plus [90] days |
| Access requests and provisioning records | [24] months |
| Support correspondence | [24] months |
| System logs required by law | Minimum 180 days, held in India |
| Backups | Rolling [35] days |
| After termination | Export window [60] days, then deletion |
You set retention and are responsible for setting it lawfully. We do not set it and cannot advise on it.
Do not place incidents, grievances or anything under investigation on short automatic deletion. Records relating to a matter that could become contentious should be placed on hold, and deletion during an open proceeding may amount to destruction of evidence.
14. Destruction register
The record destruction register requires a named witness, and destruction is refused without one. That constraint is deliberate: an unwitnessed destruction entry proves nothing if it is ever questioned, which is precisely when it will be.
Destruction entries are themselves retained. The register is a record of what was destroyed, by whom, when and witnessed by whom — and it survives the records it describes.
15. Security
Encryption in transit and at rest; uploaded files stored outside the web root; passwords stored as salted and peppered one-way hashes; forced password reset on provisioning with no password ever emailed; single-use time-limited invitation and reset links, where a fresh link kills the previous one; role-based access enforced server-side including for the read-only assessor role; multi-factor authentication for administrative accounts; tenant isolation at the data layer; immutable audit logging; rate limiting on public forms; no production data in non-production environments; verified backups tested by real restore; and periodic penetration testing.
For self-hosted or on-premise deployments: web server configuration is the only protection for uploaded files on some server software, and directory-level configuration files are ignored by others. Follow the shipped configuration samples exactly, and force HTTPS. Getting this wrong exposes patient grievances and licence scans directly.
16. If something goes wrong
- We notify you of any personal data breach affecting your data without undue delay, and in any event within [24] hours of confirmation.
- 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.
- You notify affected individuals and the Data Protection Board of India as Data Fiduciary. We provide what is required.
- We provide a written root cause analysis with corrective actions within [10] working days.
17. Legal process
Where we receive a legally binding request for hospital data, we assess its validity, challenge it where there are reasonable grounds, disclose only the minimum required, and notify you promptly unless legally prohibited. Where feasible we direct the authority to you directly, since you hold the record.
Your incident and grievance records may be sought in a claim or inquiry. That exposure exists wherever such a register is kept, including on paper. We will produce records and access logs on your instruction or lawful compulsion, and can certify integrity where asked.
18. Rights
You have direct access to your data and can export it at any time. For your own account data, write to privacy@caresoft.co.in; we verify and respond within 30 days.
For requests from patients, complainants or employees, you are the Data Fiduciary and must handle them. We assist as processor.
Erasure has limits: records within their retention period, obsoleted document versions, audit trails, destruction register entries, records on hold, and system logs required by law. We identify specifically what is retained and why.
19. Cookies
Strictly necessary cookies for sign-in, session and security; functional cookies for preferences; analytics only with consent on the public site. The signed-in platform uses no advertising or tracking cookies.
20. Contact and Grievance Officer
Privacy: privacy@caresoft.co.in
Support: support@caresoft.co.in
Grievance Officer (Information Technology Act, 2000; Digital Personal Data Protection Act, 2023)
Name: Rajeev Pillai | Email: legal@caresoft.co.in
Address: 311, Mahesh Industrial Estate , Silver Park, Mira Road East , Thane -401107 — acknowledgement within 24 hours, resolution within 15 days.
Caresoft Systems Private Limited, 311, Mahesh Industrial Estate , Silver Park, Mira Road East , Thane -401107, CIN [U72900MH2022PTC387875].
We may update this policy on [30] days' notice. Any change to §8 or §10 will be notified prominently and in advance.
Disclaimer
This Disclaimer applies to the NABHDesk website, documentation, marketing material and platform. Read it with the Independence, Trademark & Content Notice, Terms of Use and the Privacy Policy above. On any question of our relationship with NABH or of what our content is, the Independence Notice prevails.
NABHDESK CANNOT GET YOUR HOSPITAL ACCREDITED, AND WE DO NOT CLAIM IT CAN.
Accreditation is granted on an on-site assessment of what your hospital actually does. A complete set of records is necessary and nowhere near sufficient.
D1. General information only
Content on our website, documentation and proposals is general information. We take reasonable care over accuracy but make no representation as to completeness, currency or suitability for your hospital. Features and pricing change. Screenshots use illustrative data — no real hospital's records appear in any of our material.
D2. Our wording is an interpretation
Requirement descriptions, how-to notes and evidence hints are our own writing, expressing our understanding of what an element asks. They are not the published standard, not a translation of it, and not approved by anyone.
Where our wording and the published standard differ, the published standard governs. Hold your own copy, and verify our wording against it before you rely on a readiness figure (Independence Notice §10).
D3. A readiness score is your team's opinion
It reflects what your own people recorded — their judgement, their evidence, their honesty. The platform cannot detect generous self-scoring, and generous self-scoring is how most quality systems fail. A high figure produced by an optimistic team is worse than a low one produced by a rigorous team, because it stops the search.
It is not an accreditation score, not a prediction, and not evidence to a board, insurer, empanelment body or customer.
D4. Paperwork is not practice
The most common reason hospitals fail assessment is a gap between what the policy says and what staff actually do.
NABHDesk records the policy, the training, the acknowledgement and the meeting. It cannot tell you whether the night shift follows the protocol, whether the crash trolley is really checked, or whether a nurse can explain the procedure when an assessor asks.
A read acknowledgement records that someone clicked. It is not evidence that they read, understood or complied. No software can close the gap between documentation and behaviour — only leadership, training and observation can.
D5. Not an assessment, not consultancy
Nothing the platform produces is an assessment finding, a pre-assessment, or accreditation advice. A gap we show is our software's view against our library — not NABH's view. An assessor may reach a different conclusion on the same evidence, and theirs is the one that counts. The assessment-day pack is our own preparation aid, not an approved format.
D6. Scope, imports and integrations
- A readiness figure calculated against the wrong scope is meaningless, and looks exactly as authoritative as a right one.
- Imported and HIS-pushed values are not verified by us. An indicator computed from wrong source data is wrong.
- Applicability decisions are your judgement; an assessor may disagree.
D7. Standards change
Editions, amendments, clarifications and circulars are issued without notice to us. There will be periods when our library lags the published position, and we do not warrant that it reflects the current position at any moment. Knowing which edition applies to your assessment is your responsibility.
D8. Regulation sits above accreditation
Your obligations under State clinical establishment rules, biomedical waste rules, fire and building regulation, drug licensing, radiation safety, labour law and every other applicable statute apply regardless of any element. Where regulation is stricter, regulation governs, and satisfying an element does not mean you have satisfied a statute.
D9. No professional advice
Nothing on the platform or from our support team constitutes legal, regulatory, clinical, accreditation or professional advice. Caresoft is not an accreditation consultancy under this licence, and cannot advise on retention periods, applicability, your regulatory obligations or your clinical practice.
D10. Performance claims
Figures about readiness improvement, time saved, assessment outcomes or cost reduction are illustrative estimates dependent on your hospital, your starting point and your leadership. They are not commitments and are not relied upon by either party. Testimonials reflect particular experiences and guarantee nothing.
D11. Availability and security
The platform is provided on an "as available" basis without uptime commitment unless a written SLA applies. We maintain the measures in §15 above, but no system is completely secure and we do not warrant freedom from vulnerabilities. Certifications referenced are held by Caresoft Systems Private Limited within a defined scope.
D12. Disclaimer of warranties and liability
EXCEPT AS EXPRESSLY STATED IN THE TERMS OF USE, THE PLATFORM IS PROVIDED "AS IS" AND "AS AVAILABLE" WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR STATUTORY.
WE DO NOT WARRANT THAT USE OF THE PLATFORM WILL RESULT IN ACCREDITATION, ANY PARTICULAR SCORE, OR ANY PARTICULAR ASSESSMENT OUTCOME; THAT OUR WORDING CAPTURES EVERY REQUIREMENT OF ANY ELEMENT; THAT THE LIBRARY REFLECTS THE CURRENT PUBLISHED POSITION; THAT ANY READINESS SCORE IS ACCURATE OR MEANINGFUL; OR THAT IMPORTED OR HIS-SOURCED DATA IS CORRECT.
OUR LIABILITY IS LIMITED AS SET OUT IN TERMS OF USE §26. IN PARTICULAR WE ARE NOT LIABLE FOR ANY ASSESSMENT OUTCOME, NON-CONFORMITY, DELAY, REFUSAL OR WITHDRAWAL OF ACCREDITATION; THE COST OF AN ASSESSMENT OR RE-ASSESSMENT; ANY CONSEQUENCE OF RELYING ON OUR WORDING RATHER THAN THE PUBLISHED STANDARD; ANY READINESS SCORE PROVING UNRELIABLE; SCOPE DECLARED INCORRECTLY; ERRORS IN DATA YOU ENTERED OR IMPORTED; OR ANY DECISION YOUR HOSPITAL TOOK ON THE BASIS OF THE PLATFORM.
Nothing limits liability for fraud, death or personal injury caused by negligence, or any liability that cannot lawfully be limited. Governed by the laws of India, subject to Terms of Use §29.