Security and Compliance

RxPulse handles protected health information for families enrolled through partner programs. The platform is built to HIPAA-aligned technical and process controls. This page summarises the posture so a procurement team can orient quickly, then ask for the partner-specific documentation when a closer review is in order.

We are deliberate about what we claim. RxPulse is pre-launch: it is not yet certified or independently audited, and no SOC 2 report exists. The controls below are technical safeguards implemented in our code, not third-party attestations. Where a control is live, we say so and point at the mechanism. Where work is committed for production launch, we label it as a commitment rather than a current capability.

Clinical records are protected by PostgreSQL Row-Level Security that fails closed and is force-applied, so the policy binds even the table-owner role. A database connection that has not established an authenticated user identity for the transaction cannot read or write clinical rows, which means application code cannot accidentally step around the access boundary. Row-Level Security currently covers the clinical PHI tables (medications, vitals, lab results, conditions, care plan, meal plans, workout schedule, daily actions, follow-up alerts, and medication proposals), with database audit triggers extending coverage to the wider set of PHI-bearing tables.

Cross-origin access to our FHIR and clinical-decision-support endpoints is restricted to an explicit, environment-configured origin allowlist. There is no wildcard origin, and an unconfigured or unmatched origin receives no cross-origin grant. Queries run through a typed data layer with parameterised statements.

Member records are stored in a managed PostgreSQL environment. US and EU regional placement can be accommodated through our managed-database provider's regional options as part of partner onboarding; backup and failover stay within the same residency boundary unless a partner agreement specifies otherwise. Region selection is handled at provisioning time during onboarding, not as a self-service product setting.

All traffic is served over HTTPS, and the application sets HTTP Strict Transport Security (HSTS) with a two-year max-age, includeSubDomains, and preload, so browsers are instructed to use TLS for every connection. Database connections require TLS. Encryption at rest is provided by our managed PostgreSQL provider as a property of the hosting environment. Application-level encryption for specific fields can be added on partner request where a downstream regulatory requirement calls for it.

Responses also carry a defense-in-depth header set: a Content-Security-Policy with frame-ancestors set to none, X-Frame-Options DENY, X-Content-Type-Options nosniff, a strict Referrer-Policy, and a restrictive Permissions-Policy.

Authentication uses self-hosted Better Auth backed by our managed Postgres store, with httpOnly, secure-prefixed session cookies over HTTPS. Roles are server-controlled: the role field cannot be set by the client, and role changes flow only through an admin-only endpoint that re-checks the caller's session role, validates input, writes an audit record, and revokes the affected user's existing sessions. Public self-service sign-up is disabled; accounts are provisioned only through admin and clinic-admin invitation flows.

Authentication parameters are set to HIPAA-aligned values: a 12-character minimum password length is enforced on every account-creation path, and sessions apply an automatic 30-minute inactivity timeout. The session window slides while you are active and expires once a session goes idle, in line with the automatic-logoff control under 45 CFR 164.312(a)(2)(iii).

Access paths to protected health information write an audit record capturing who accessed it, what resource, when, and from where (IP and user agent). Audit writes are fault-isolated, so logging can never block or crash the underlying request, and a redaction pass strips known sensitive fields (for example MBI, social security number, date of birth, phone, and address) from audit metadata before it is persisted.

The audit log is enforced append-only at the database layer: a PostgreSQL trigger rejects any update, delete, or truncate against the audit table. Retention is governed by the partner agreement and the relevant regulatory floor.

Our infrastructure sub-processors include a managed application-hosting platform, a managed PostgreSQL provider (encrypted at rest and in transit), and a CDN and edge provider. Where AI and voice features process patient context, the relevant model and voice providers are sub-processors; those features stay gated for PHI until a Business Associate Agreement is executed with each provider. A current, engagement-scoped sub-processor list, including the data categories each one receives, is shared on request as part of procurement, and material changes are communicated to partners with reasonable notice.

RxPulse has not yet executed Business Associate Agreements with its AI and infrastructure vendors. Our policy is to execute a BAA, or route through a vendor's BAA-covered path, with every sub-processor before any real PHI is processed in production. We also sign a BAA with partners whose engagement touches PHI; the standard template covers permitted uses and disclosures, safeguards, sub-processor flow-down, breach notification, and mutual indemnification consistent with the HIPAA Privacy and Security Rules, and partner-specific redlines are accommodated. To request a draft, reach us via our contact page.

We maintain a documented incident-response and breach-notification process, including severity tiers and a 72-hour target for notifying affected individuals and the relevant authority, with the partner-specific window in the BAA usually tighter than the regulatory floor. Notifications describe the nature of the incident, the categories of records affected, and the remediation in flight. Finalising and operationalising this plan, including the contact path agreed in the BAA at engagement start, is part of our pre-launch readiness work.

Continuous integration runs a Trivy filesystem and dependency vulnerability scan for critical and high severity findings on every push and pull request, and every change must pass an automated lint gate before merge. We pin transitive dependencies away from known-vulnerable releases at the resolution layer; for example, a package-manager override forces postcss to a patched release (8.5.10 or higher). Sensitive and abuse-prone API routes apply per-route rate limiting that returns standard rate-limit responses.

On the hardening path: a distributed, multi-instance rate limiter and a build-failing severity gate on the vulnerability scan are part of production hardening. Security inquiries and vulnerability reports are triaged through the contact path below.

The platform is built to align with HIPAA Security and Privacy Rule controls. Our privacy policy is grounded in the GDPR and the Swedish Patient Data Act (Patientdatalagen 2008:355), maps each processing purpose to a legal basis, and enumerates the data-subject rights (access, rectification, erasure, portability, objection, and restriction). To exercise a right such as erasure, partners and members contact us and the request is handled per our documented workflow and applicable retention limits.

To be clear about status: RxPulse is pre-launch. It is not HIPAA-certified, not SOC 2 audited, and has no signed BAAs today. SOC 2 Type I is planned and is not yet underway. For partners participating in the CMS ACCESS Model or similar value-based programs, reporting alignments (FHIR data models, audit-ready longitudinal data) are part of the standard engagement; the live CMS submission path is in progress and currently operates in a rehearsal mode pending the published submission specification.

Security inquiries, vulnerability reports, and compliance documentation requests all route through our contact page. A dedicated security inbox is on the roadmap; for now the contact form is monitored and security messages are tagged so they reach the right person quickly.

Last reviewed: 2026-05-30.