Skip to content
Security & trust

Built for patient data, and the people accountable for it.

Family Guardian AI handles some of the most sensitive data there is — the health of high-risk Medicare patients. This page lays out how we protect it: how data is encrypted and access is scoped, how our HIPAA compliance is built in, how every PHI-handling subprocessor is covered, and how the physician sign-off gate doubles as a clinical-safety control.

  • HIPAA-compliant
  • BAA-ready
  • CPT 99490-native
  • Transparent AI
Security · posture

Trust posture

The controls a security reviewer asks about first.

HIPAA-compliant
  • Business Associate AgreementRequired

    Signed before any real patient data flows

  • EncryptionOn

    In transit and at rest

  • AccessScoped

    Scoped per customer and role

  • Telemetry & error monitoringClean

    PHI kept out

Every PHI-handling subprocessor is under its own BAA. The full list is shared under NDA.
Clinical content is gated on a physician sign-off before it runs.
Illustrative · sample data
Stated plainly

We are HIPAA-compliant, and we sign a BAA before any real patient data flows.

Our practices follow the HIPAA Security Rule — encryption in transit and at rest, scoped access, and audit logging — and we sign a Business Associate Agreement with every customer and every PHI-handling subprocessor before any patient data moves. We'll walk your security team through every control.

Data protection

Patient data is protected at every step.

The basics, done properly. Data is encrypted wherever it lives, access is narrow by default, and the tools we use to keep the system running are kept clear of patient details.

Encrypted in transit and at rest

Patient data is encrypted on the wire and encrypted where it's stored. There is no point in the flow where it sits in the clear.

Access is scoped, not open

People and services see only the patients they're meant to. Access is tied to a customer and a role — not a shared key that opens everything.

PHI stays out of telemetry

Our logging and error monitoring are built to capture what broke without capturing who it broke for. Patient details don't leak into the tools we use to keep the system healthy.

HIPAA posture

Where we stand, said precisely.

We're HIPAA-compliant: the product is built around the HIPAA Security Rule, and a signed Business Associate Agreement is a precondition for handling real patient data — not a formality we get to later.

  • Built around the Security RuleEncryption, scoped access, and audit logging are designed in — the controls HIPAA asks for, in the product itself.
  • A BAA before any real dataWe sign a Business Associate Agreement with every customer before a single real patient record moves. No BAA, no PHI.
  • Ready for your security reviewWe map every control to the HIPAA Security Rule and walk your team through it — compliance you can verify, not just take on faith.
Subprocessors

Every subprocessor that touches PHI is under a BAA.

We rely on a small set of vendors to run the product. Every one of them that can see protected health information is covered by its own Business Associate Agreement — so the chain of accountability runs unbroken from your patients to us to anyone we depend on.

The full list, under NDA

We don't publish vendor names on a public page — but we share the complete list during diligence, under NDA: each subprocessor, what it does, and the BAA behind it. A buyer evaluating us sees all of it.

  • Only vendors that need PHI ever receive it.
  • Each one is covered by its own BAA before any data flows.
  • The list is kept current and shared on request.
Audit & access logging

Who saw what, and who did what — kept on the record.

Because this is clinical data under your team's name, the trail behind it has to hold up. Access and clinical actions are logged, and any call can be traced to the exact content that ran it.

Clinical actions are logged

When someone reviews a concern, resolves an alert, or signs off a workflow, it's recorded — who did it and when. The trail is kept, not overwritten.

Calls trace back to content

Any call can be traced to the exact signed version of the workflow that ran it, so a reviewer can always reconstruct what a patient actually heard.

Access is attributable

Sessions are tied to a named account on your side. There are no anonymous shared logins reaching real patient data behind the scenes.

Physician sign-off gate

The sign-off gate is a safety control, not just a feature.

No workflow runs with real patients until a supervising physician signs it off — enforced in the database.

No clinical content reaches a real patient until a supervising physician on your side reads it, edits it, and signs it off. Until that sign-off exists, the system simply won't assign the workflow to a real patient. It extends the reach of your care team — it never replaces a clinician, diagnoses, or prescribes.

  • Your physician owns itThe supervising physician is on your side. You decide what the AI covers and where the line sits.
  • Enforced in the databaseAn unsigned workflow can't run on a real patient. The block is a state the system holds, not a rule people must remember.
  • On the recordWhich physician signed which version, and when, is logged alongside the workflow.
At a glance

The short version of how we treat your trust.

  • HIPAA-compliant
  • BAA-ready
  • CPT 99490-native
  • Transparent AI
Questions buyers ask

Straight answers, before the pilot.

If your question isn't here, ask on the intro call — we answer every one of them with whoever signs the BAA.

  • How does Family Guardian AI handle HIPAA and PHI?

    Family Guardian AI is HIPAA-compliant: the product is built around the HIPAA Security Rule — encryption in transit and at rest, scoped access, and audit logging — and we sign a BAA with every customer before any real patient data flows. We'll walk your security team through every control.

  • Will you sign a BAA?

    Yes. A signed Business Associate Agreement is the gate to a pilot — it comes before any real patient data moves, not after. Every subprocessor that touches PHI on our side is itself under a BAA, so the chain of responsibility is unbroken from your patients to us to anyone we rely on.

  • Who are your subprocessors?

    We share the full list of PHI-handling subprocessors under NDA during diligence — names, what each one does, and the BAA behind it. We don't publish vendor names on a public marketing page, but we hide nothing from a buyer who's actually evaluating us.

  • Has a physician reviewed the clinical content today?

    No — and we won't pretend otherwise. The workflows in the product right now are drafts built from published guidance, scaffolding for a physician to review. No workflow runs with real patients until a supervising physician on your side signs it off, and that block is enforced in the database, not left to anyone's memory.

  • Do you bill on our behalf?

    No. You bill; we document. Each qualifying call is structured into the documentation Medicare asks for under CPT 99490 — we generate the documentation, not the reimbursement. Whether a claim is payable depends on your practice meeting CMS requirements.

  • Can we see this before a pilot?

    Yes. We'll walk a security reviewer through the data-handling posture, the subprocessor list under NDA, and the audit trail in the real product — in a working session, not a slide deck. Ask on the intro call and we'll set it up with whoever signs the BAA.

Clinical safety has its own page — how the AI is steered, what it escalates, and where the physician sits in the loop.

See clinical safety

Bring your security reviewer. We'll open the hood.

In a twenty-minute walkthrough we'll show the data-handling posture, share the subprocessor list under NDA, and walk the audit trail in the real product — the answers your diligence needs, not a slide deck.

A real person replies — usually the same business day. No sales sequence, no obligation.