Your health record is among the most sensitive data you own. This page describes the safeguards that protect it — and is honest about what is in place today versus what is still on our roadmap.
Layered, practical controls that are running in production now.
Every request travels over HTTPS/TLS, with HSTS instructing browsers to refuse any unencrypted connection to us. Data is encrypted in transit end to end.
We never keep your password. It is one-way hashed with bcrypt, so even we cannot read it — and a database copy would not reveal it.
You choose: an authenticator app (TOTP), a one-time email code, or a passwordless email sign-in link. Add a second factor for stronger protection whenever you want.
Repeated failed sign-ins are rate-limited per account and per network, with cooldowns and automatic blocking of persistently abusive addresses.
A Content-Security-Policy, clickjacking protection (frame-ancestors), MIME-sniffing defence, and a strict referrer/permissions policy ship on every page. Sensitive pages are marked no-index.
Access is role-based and scoped to the minimum needed. You grant professionals access to specific parts of your record — not the whole thing — and you can revoke it at any time.
Before anything is sent to an AI or research pipeline, it is de-identified: your age instead of your date of birth, and names, contacts and identifiers stripped or redacted. Your identity is never sent to a third-party model.
Sensitive and administrative actions — API calls, access grants, trust-and-safety events — are logged, so activity on your record is accountable and reviewable.
Uploads are checked against a harmful-content blocklist, sharing is risk-based with limits on unusual activity, and recipients can report misuse for review.
Application secrets and configuration are held outside the web-servable path and cannot be downloaded. Keys are never exposed as static files.
Our FHIR API uses OAuth2 with scoped bearer tokens. Each client is confined to the data its own services produced, and outbound webhooks are HMAC-signed so recipients can verify authenticity.
We capture your consent at registration in line with GDPR, and record the purpose and legal basis for processing your health data.
These protections are designed and agreed but not yet in production. We list them so you know the direction of travel — not to imply they are live today.
Field-level encryption with keys held so that OmniHealth itself cannot read your record — paired with a mandatory, user-held recovery mechanism so you never lose access.
Encrypted record fragments stored across separated locations, with per-country residency, so no single store holds a usable copy of your data.
Regular third-party penetration testing and independent security review, with results feeding directly back into the platform.
We welcome responsible disclosure. If you believe you have found a security issue, email security@omnihealth.solutions with enough detail to reproduce it. Please give us reasonable time to investigate and fix the issue before disclosing it publicly, and avoid accessing or modifying other people’s data while testing.
We will not pursue legal action against good-faith research that respects those boundaries. If a security incident affects your personal data, we will notify affected users and the relevant regulator (such as the ICO) as required by law.
This page reflects the security controls implemented as of the current release. It is reviewed as the platform evolves.
