Security & data

Designed to route the decision without handling the identity.

CareFWD’s guiding principle is that finding where a patient can go should not require sharing who the patient is. This page is written for hospital IT and compliance reviewers; it says what we hold, what we don’t, and how to verify it.

Last updated September 24, 2026 · Download the one-page PDF

What CareFWD is

A care routing network for hospital discharge planners: the step before a referral. A planner posts an anonymous Care Transition Query, matching post-acute providers answer whether they can take the case, and the planner chooses. The referral itself, with the patient’s identity, then happens in your existing systems.

What we hold, and what we don’t

DataHeld?Notes
Patient identity (name, date of birth, MRN, SSN, address, phone)NoThere is no field for it. Identifier-shaped text is blocked at entry and again server-side.
Care Transition QueryYes, anonymousCare category, destination ZIP, payer type, free-text needs. No patient identity.
Care manager and provider accountsYesName, work email, title, role, organization. Passwords are handled and hashed by the authentication provider and are never stored by CareFWD.
Facility and provider business dataYesPublic business information: address, phone, fax, website, NPI, CMS rating.
Clinical records, referral packets, insurance member IDsNoThese stay in your hospital's referral workflow and systems.

How patient identity stays out

  • Anonymous by construction.

    A routing query carries only non-identifiable details and is not intended to hold PHI.

  • Guardrails at entry.

    The composer blocks common identifiers and discourages identifying free text before a query is ever sent. The same screen runs again on the server before anything is stored.

  • Two-way anonymity.

    Providers don't see the patient or the care manager; the query stands alone.

  • Identity exchanged later.

    Contact and clinical detail move only after a provider is chosen — through your hospital's existing HIPAA-compliant referral process, not through CareFWD.

  • Minimal by design.

    We collect only what routing requires and keep resulting insights non-identifiable.

Where it runs

  • Application served by Cloudflare’s network, which terminates TLS and absorbs DDoS traffic in front of every request.
  • Database, authentication and file storage on Supabase, in AWS region ca-central-1 (Montréal, Canada).
  • Encrypted in transit (TLS 1.2 or newer, HSTS enforced) and at rest (AES-256 on the database provider’s storage).
  • Automated daily database backups by the database provider.
  • No data is sold, and none is used for advertising.

Who can see what

  • Every account is reviewed and approved by a CareFWD administrator before it can see anything; no one can grant themselves elevated access.
  • Role-based access: planners, provider representatives and administrators each see only their own surface.
  • Row-level security is enforced inside the database on every table, so access rules hold even if application code has a bug.
  • Privileged service credentials exist only on the server and are never sent to a browser.
  • Administrative actions are written to an audit log, and every contact-sharing consent is recorded in an append-only ledger enforced by the database.
  • An idle-session timeout is built in and can be enabled per deployment. Multi-factor authentication for user accounts is on the near-term roadmap.

How we operate

  • Secrets live in the hosting provider’s encrypted secret store, never in source code, with a written rotation runbook.
  • Every change goes through code review, an automated test suite (type checks, lint, unit, browser and database regression tests) and required status checks before it can reach production.
  • Dependencies are updated on a weekly automated schedule.
  • Browser security headers (Content-Security-Policy, HSTS, frame denial, referrer and permissions policies) are sent on every response.
  • Analytics run on the public marketing pages only and are never loaded inside the logged-in portals.

Compliance posture, stated plainly

CareFWD is architected so that no protected health information is stored or transmitted through the platform. We do not currently hold a SOC 2 report. Our controls are aligned to the SOC 2 Trust Services Criteria and the HIPAA Security Rule safeguards, and a SOC 2 audit is planned as customer volume grows. We will complete your vendor security questionnaire (SIG Lite, HECVAT or your own form) and will sign a Business Associate Agreement if your review determines one is required.

Subprocessors

Every third party that touches CareFWD data, and why.

ProviderPurposeLocation
CloudflareApplication hosting, DNS, TLS, DDoS mitigation, inbound email routingGlobal edge; US-based company
SupabasePostgreSQL database, authentication, file storageAWS ca-central-1 (Montréal, Canada)
Google Analytics 4Visit counts on public marketing pages only; never inside the portalsUnited States
Google Maps Platform (Places)Server-side lookup of facility business detailsUnited States
CMS.gov and NPPES (public datasets)Provider ratings and NPI validation; outbound reads onlyUnited States

Reporting a security concern

Write to security@care-fwd.com. We acknowledge reports within two business days. If we confirm an incident affecting your organization’s data, we will notify you within 72 hours of confirmation, with what happened, what was affected and what we are doing about it.

Not an EHR, not a PHI-carrying referral system, and not a payer directory: CareFWD is the patient-first decision step ahead of them.

Need this for a vendor review?

Send your IT or InfoSec contact this page or the PDF. We will answer their questionnaire and walk your compliance stakeholders through the details.