Security

Security architecture and HIPAA posture.

Hospice Helper is built on a HIPAA-aligned architecture, with documented security policies, an AWS Business Associate Agreement in place, and full logging and audit-trail maturity. We are on track for SOC 2 certification. The detail that follows is provided for the personnel on your team — or your accreditor's team — who require it.

Summary

Patient data is encrypted in transit and at rest. Each agency's information is isolated from every other agency on the platform. Every access and every change is captured in an audit log that cannot be altered by the application itself. AI-assisted review operates only within the same BAA boundary as the rest of the platform. A Business Associate Agreement is executed before any production protected health information is processed.

Architecture and controls

Encryption in transit and at rest

TLS 1.2 or higher is required between every client and the service, and between the service and its data stores. Document storage and database storage are encrypted at rest with keys managed by AWS Key Management Service.

Standard: HIPAA Security Rule §164.312(a)(2)(iv), §164.312(e)(1)

Multi-factor authentication required for administrative access

Multi-factor authentication is mandatory for every administrative role. The platform does not expose a configuration that permits administrative accounts to operate without it.

Standard: HIPAA Security Rule §164.312(d)

Append-only audit log enforced at the database

The application's database role holds no UPDATE or DELETE privilege on the audit log table. A compromised application process cannot alter or remove audit entries; only an out-of-band administrator operating with separate credentials may read them. Every read and write of protected health information is captured.

Standard: HIPAA Security Rule §164.312(b)

Tenant isolation via row-level security

Each agency is provisioned as an isolated tenant. Every request establishes a session-local tenant identifier, and PostgreSQL row-level security enforces that records belonging to one agency cannot be returned by a query executed for another. The isolation is enforced at the database layer rather than in the application, and persists in the presence of application-layer defects.

Standard: HIPAA Security Rule §164.312(a)(1)

Production hosting on AWS

The application runs on Amazon ECS Fargate in us-east-1, behind an Application Load Balancer with AWS WAF. The Postgres 16 database operates in private subnets with no public ingress, and document storage is provided by KMS-encrypted S3. The marketing site you are reading is a separate, static origin and does not share infrastructure with the application.

Standard: HIPAA Security Rule §164.308, §164.312

AI processing within the BAA boundary

AI-assisted review is a core capability of the platform. Every model provider involved in processing protected health information operates under a signed Business Associate Agreement before incorporation into the production environment. PHI is not transmitted to model endpoints that are not under BAA. Models surface evidence and explain their findings; clinical judgment and the responsibility for changes to the record remain with the agency's clinicians.

Standard: HIPAA Security Rule §164.308(b), §164.314(a)

Original EHR payloads preserved alongside canonical records

Every ingest preserves the source payload — the CSV row, the FHIR Bundle, the PDF — alongside the canonical record. Surveyors and quality investigators can compare exactly what the source system transmitted against the platform's interpretation.

Standard: 42 CFR Part 418 — surveyor evidence requirements

Tenant-local time zones for regulatory deadlines

HOPE windows, face-to-face deadlines, and "within N calendar days" requirements are computed in the agency's primary time zone, not in UTC. A HUV2 window in Hawaii does not close at 8 p.m. local time because the platform's servers are operated in us-east-1.

Standard: HOPE submission specifications; 42 CFR Part 418

Documented policies and SOC 2 readiness

Hospice Helper maintains a written security program that governs the operational practices behind the architectural controls above. The following policies are documented and exercised:

Access control and least-privilege provisioning
Incident response and breach-notification procedures
Change management for production systems
Vendor and subprocessor review, including BAA execution
Workforce onboarding, role training, and offboarding
Data retention, backup, and recovery

Copies of relevant policy excerpts are available under non-disclosure in response to a security questionnaire or vendor-risk request.

SOC 2 readiness in progress

Hospice Helper is actively working toward SOC 2 Type II attestation, with the supporting policy library and evidence collection already underway. We use the phrase "on track for SOC 2 certification" deliberately — SOC 2 attestation will be named on this page only once formally completed by our auditor.

We do not claim HIPAA certification — HIPAA has no certification body. The accurate framing is alignment with the HIPAA Security Rule §164.312 administrative, physical, and technical safeguards, which is what the controls above describe.

Business Associate Agreements

Hospice Helper maintains a signed Business Associate Agreement with Amazon Web Services and requires a BAA from every downstream vendor — including AI model providers — with potential access to protected health information before that vendor is incorporated into the production environment.

When an agency is onboarded, Hospice Helper executes a BAA with the agency before any production PHI is processed. There are no exceptions to this sequence.

What this site does not do

This website is informational. It collects no protected health information, sets no tracking cookies, and uses no third-party analytics beyond a cookieless measurement tool. Protected health information is processed only inside the authenticated application at app.hospice-helper.com, which is a separate, AWS-hosted system.