We hold ourselves to the standard we audit clients against.
Ralt Health serves independent physician practices, many of whom are HIPAA covered entities. This page documents our security posture, data-handling principles, BAA availability, and the compliance roadmap we’re executing on.
HIPAA posture
The website. ralthealth.com is a marketing and discovery surface. We do not solicit, collect, or process Protected Health Information through it. Our Privacy Policy explicitly requests that visitors not submit PHI through our contact forms.
Ralt Rounds. The SaaS product is currently in a no-PHI v1. Practice staff interact with anonymous per-visit codes (format P-XXXX) and operational signals like billing-event state and provider productivity. No names, dates of birth, medical record numbers, or clinical details enter our database in v1. Staff cross-reference the P-code to the practice’s EHR or billing system, which is where the PHI actually lives.
BAAs.For customers that are HIPAA covered entities, we offer Business Associate Agreements as part of service engagements. A BAA is signed before any engagement in which Ralt Health may create, receive, maintain, or transmit PHI on the customer’s behalf. Our BAA template is available on request.
How our website scanner works
Scope & passive methodology. Our scan performs automated, non-invasive analysis of publicly accessible web pages and server configuration — public HTTP/HTTPS response headers, SSL/TLS configuration, DNS and email-authentication records, WCAG accessibility, client-side scripts and third-party trackers, and page-performance metrics. It does not perform vulnerability exploitation, port scanning, brute-force testing, or form submissions, and it does not attempt to access non-public directories, administrative portals, or authenticated systems. Deeper file-exposure testing is performed only for engaged customers who have authorized it in writing.
HIPAA & Protected Health Information. The scanner analyzes only open infrastructure and client-side code visible to any standard web browser. It does not request, ingest, process, store, or transmit PHI or electronic health records. It does not authenticate to patient portals, and it does not submit or enter personal information into appointment-request or medical intake forms.
Point-in-time & accuracy. Scan results, scores, and reports represent an automated snapshot of a public domain at the time of execution; web configurations change frequently. Reports are provided on an “AS IS” basis for informational and educational purposes only and do not constitute a formal legal, compliance (including HIPAA or ADA), or cybersecurity audit. Site owners should independently verify findings before making changes.
Access method & respect for protocols. Our scanner retrieves publicly accessible pages the same way a standard web browser does — it requests only public resources, reads what the server returns, and performs all analysis on our own systems. It honors robots.txt directives (including disallowed paths and any crawl-delay), applies conservative rate limiting and short timeouts to avoid meaningful load on the target server, and does not authenticate to, bypass access controls on, or disguise itself as a specific person or organization. Site owners and administrators can identify and reach us through the opt-out below and at our scanner information page.
Domain opt-out. If you are a practice owner or IT administrator and wish to exclude your domain from our scanning, email contact@ralthealth.com with the domain. We honor opt-out requests within five business days.
Data handling principles
No PHI in v1
Our website does not collect or process Protected Health Information. Ralt Rounds is currently in a no-PHI v1: operational data flows through anonymous per-visit codes rather than patient identifiers. PHI-capable modules will ship only with separate schema, encryption, and audit controls.
Minimum necessary
We only ingest the data required to compute the findings in your engagement. We do not request EHR access or billing exports — our analytics are built on public CMS claims data plus signals you explicitly share.
Append-only audit trail
Every read and write of practice-scoped data is logged. Database triggers reject UPDATE and DELETE on the audit log. History survives the application layer — a compromised role cannot scrub the record.
Vault-encrypted integrations
Third-party integration tokens (Microsoft Graph, future EHR connectors) are stored with authenticated libsodium encryption, versioned from day one so keys can rotate without re-integration.
Security controls
Transport
TLS 1.3 everywhere. HSTS with preload. Strict Content Security Policy. X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy headers on every response. Cookieless first-party analytics (Cloudflare Web Analytics).
Authentication
Microsoft Entra SSO for staff access. TOTP multi-factor enforced at enrollment. Session timeout enforced per role. Role-based module access via a central registry.
Tenant isolation
Single-tenant cloud architecture: each practice runs on its own Postgres (Supabase) project and Vercel deployment. No shared database. Tenant-scoped queries enforced in code and reviewed at every module.
Observability
Sentry error monitoring with sensitive-field scrubbing at the edge. Structured logging (pino) with redaction. Every Graph API call telemetered for debugging without exposing tokens.
Encryption at rest
Customer state lives in Postgres (Supabase), encrypted at rest with AES-256 by default. Highly sensitive fields receive additional column-level encryption via Supabase Vault. Daily backups inherit the same at-rest encryption.
Data residency
Ralt Rounds provisions each practice on infrastructure hosted in United States regions (Supabase database and Vercel application). The specific hosting region and data-residency terms are confirmed in writing at onboarding, as part of the BAA.
Vulnerability management
Dependencies are monitored continuously — Dependabot on our product and engine repositories, plus npm audit and pip-audit gates that flag known CVEs (OWASP A06). Automated accessibility, Lighthouse, and security-header checks run in CI on every change. An independent third-party penetration test is planned alongside our SOC 2 Type I work.
Compliance roadmap
Where we are today, where we’re going, and what’s on the horizon.
| Standard | Status | Notes |
|---|---|---|
| HIPAA Security Rule (45 CFR §164.302–318) controls | Implemented | Technical, administrative, and physical safeguards mapped to implementation in our internal controls catalog. BAAs available on engagement. |
| HIPAA Privacy Rule posture | Scoped | Documented in our Privacy Policy. Consistent with the no-PHI v1 scope and will expand when PHI modules launch. |
| WCAG 2.2 AA accessibility | Implemented | axe-core verified. See our Accessibility Statement. |
| Section 504 / ADA Title III alignment | Implemented | Covered by the same WCAG conformance work. Relevant to customers receiving federal financial assistance. |
| SOC 2 Type I readiness | In progress | Target: Year 1 engagement. Control catalog, incident-response policy, change-management policy, and access-review cadence already in place. |
| HITRUST CSF | Roadmap | Year 2+ target, triggered by first enterprise customer requiring it. |
Related documentation
Subprocessors
Full list of third-party services that process data on our behalf, with BAA status per vendor.
Privacy Policy
How we collect, use, and protect data submitted through the website and across our services.
Accessibility Statement
WCAG 2.2 AA conformance commitment, testing methodology, and accommodations contact.
Terms of Service
Engagement terms, governing law, BAA references, and customer responsibilities.
Need a BAA or a security questionnaire?
Email us directly. We typically respond within one business day and can share our BAA template, SOC 2 readiness summary, or fill out your standard security questionnaire.
contact@ralthealth.com