Privacy Policy

Effective date: 28 August 2026 Controller/Operator: Neem Health Inc. ("Neem Health", "we", "us") Contact: admin@neemhealth.ai

1. Who this policy covers

Neem Health Connect is a backend platform used by Developers to ingest, normalize, and read health-related data on behalf of their End Users. This policy explains what we collect, why, and how it's protected.

• If you are a Developer, this policy covers your account data (email, password hash, API keys) and your role as the party responsible for your End Users' consent.
• If you are an End User of a Developer App built on Neem Health Connect, this policy covers the health, calendar, and email-metadata records ingested on your behalf. Your direct relationship is with the Developer's app, not with us — contact them first for access, correction, or deletion requests; they can also relay those requests to us, or you can contact us directly at admin@neemhealth.ai.

2. What data we process

2.1 Developer account data

Email address, hashed password (scrypt, salted), hashed API keys and refresh tokens (plaintext shown once at creation, never stored or logged again).

2.2 End User data, by source

All source data is normalized into a canonical model before storage. We never store more than the source natively exposes, and several categories are metadata-only by design:

2.3 What we do not collect

• We do not collect data directly from End Users; all data arrives through a Developer's authorized integration.
• We do not use End User health data for advertising, and we do not sell personal data.
• Email and message bodies are never stored, regardless of configuration.

3. Why we process this data

• To provide the ingestion, normalization, storage, and read-API functionality that Developers integrate into their apps.
• To maintain sync state (last successful sync, error status) so Developer Apps can show connection health to End Users.
• To detect and prevent abuse of the platform (e.g., rate limiting, anomalous access patterns).
• For PHI specifically: only to fulfill an EHR data-retrieval request for which active consent has been recorded, and only for the Developer that obtained that consent.

We do not use End User data to train models, for our own research, or for any purpose beyond operating the Service for the Developer that connected it, unless we obtain separate, explicit consent to do so.

4. Legal bases (where applicable, e.g. GDPR)

• Consent — for connecting a source (OAuth authorization, or explicit consent capture for EHR/PHI access).
• Contract — for Developer account data, to provide the Service under our Terms.
• Legitimate interest — for security logging, abuse prevention, and audit trails.

For End User health data, Neem Health acts as a processor on the Developer’s documented instructions; the Developer is the controller and is responsible for establishing and evidencing a lawful basis with its End Users. Developers established in the EU or UK should request a Data Processing Agreement at admin@neemhealth.ai before processing personal data of individuals in those jurisdictions.

5. How data is protected

• Two isolated data stores. Non-PHI wellness data (device/wearable/ calendar/email) and PHI (EHR records) live in physically separate databases with no cross-links other than a shared opaque user identifier. This is enforced by an automated boundary test, not just policy.
• Encryption in transit. All traffic to and from the Service is HTTPS/TLS; all upstream provider calls (Whoop, Oura, Google, Microsoft, health systems) are HTTPS-only.
• Encryption at rest. OAuth tokens and credentials are encrypted (AES-256-GCM) before storage — plaintext tokens are never persisted. Databases are encrypted at rest by the cloud provider.
• Audit logging for PHI. Every read, write, or deletion of PHI records the acting party, the action, the resource, and the reason, written before the operation occurs, and the audit log itself is append-only (cannot be edited or deleted through normal application access).
• Access control. PHI is only reachable through audited service code — there is no path in the codebase that bypasses these controls, verified by an automated test on every change.
• Consent gating for EHR data. No clinical record is ever fetched from an EHR source unless active, recorded consent for that specific purpose exists.
• Known current limitations (tracked in docs/HIPAA_CHECKLIST.md, addressed on an ongoing basis): encryption keys are not yet rotated on a schedule; developer dashboard accounts do not yet support multi-factor authentication; formal BAAs with our infrastructure and EHR vendors are in progress and production PHI traffic will not go live ahead of them.

6. Who we share data with (subprocessors)

• Cloud infrastructure: Microsoft Azure (Container Apps, Database for PostgreSQL, Key Vault, Communication Services), Central US region — hosts all data; BAA status: pending.
• Source providers, only to the extent needed to sync the data you authorized: Whoop, Oura, Google (Calendar/Gmail), Microsoft (Outlook Calendar/Mail), Apple (via the Developer's mobile app), the End User's own health systems (EHR connectivity).
• We do not sell data to third parties, and we do not share End User data across Developer tenants.
• Each Developer only ever sees the data belonging to their own tenant.

7. Data retention and deletion

• Data is retained for as long as the Developer's account is active and the End User has not requested deletion, or per the Developer's own retention configuration.
• End Users (via their Developer App) or Developers directly can request full erasure through DELETE /me/data, which removes wellness records, PHI records, consent records, and EHR links tied to that End User.
• Exception: audit log entries documenting historical PHI access are retained even after the underlying record is deleted, as required for compliance and security accountability. Audit entries do not themselves contain clinical content — only identifiers, actions, and timestamps.
• Retention. Records are kept for as long as the source remains connected and the account is open. There is no automatic expiry: data is removed when a Developer or End User requests deletion (DELETE /me/data, which erases canonical records, archived source payloads, connected-source registrations, stored tokens, and PHI), or when an account is closed. The append-only audit trail is the documented exception described above.

8. Your rights

Depending on your jurisdiction, you may have the right to access, correct, export, or delete your data, and to withdraw consent for a specific integration at any time (which stops future syncing; it does not retroactively un-sync data already ingested unless you also request deletion).

To exercise these rights: contact the Developer App you use directly, or email admin@neemhealth.ai and we will coordinate with the relevant Developer.

9. Children's data

The Service is not directed at children, and Developers are responsible for ensuring their own End User base and consent flows comply with applicable children's privacy law (e.g., COPPA) if relevant to their app.

10. International data transfers

All data is hosted in Microsoft Azure, Central US. Both databases, the application, and its logs reside in that region; nothing is replicated outside it. Developers and End Users located elsewhere should note that their data is processed in the United States. Developers established in the EU or UK should request a Data Processing Agreement, incorporating Standard Contractual Clauses where required, at admin@neemhealth.ai.

11. Changes to this policy

We may update this policy from time to time. Material changes will be communicated to Developers via a notice on the developer dashboard and an email, who are responsible for notifying their End Users as required by their own agreements.

12. Contact

Questions or requests regarding this policy or your data: admin@neemhealth.ai