HIPAA — Health Insurance Portability & Accountability Act
United States healthcare data protection standard
Privacy Rule
- All 18 HIPAA-defined PHI identifiers encrypted at column level using pgcrypto (AES-256)
- Minimum-necessary access enforced via Row Level Security — roles only see data required for their function
- Family portal access scoped to linked residents only via
family_resident_links - De-identified analytics exports strip all PHI before leaving the database
- Consent management tracked per resident in the clinical profile
Security Rule
- Encryption at rest: Aurora KMS Customer Managed Key (CMK)
- Encryption in transit: TLS 1.2+ enforced on all connections (
rds.force_ssl = 1) - Access control: RBAC with five user roles + PostgreSQL Row Level Security
- Audit controls: immutable
auditschema with append-only grants - Automatic session expiration; device fingerprint tracking
- Break-glass emergency access flagged with mandatory reason field
Breach Notification Rule
- Incident table (
phi.incidents) tracks severity, affected residents, and resolution - CloudWatch Logs Insights triggers alerts on anomalous access patterns
- Security team notified within 1 hour of suspected breach event
- Notification to affected individuals within 60 days (US requirement)
- HHS reporting procedures documented in the incident response runbook
Business Associate Agreement
- AWS BAA signed covering Aurora RDS, S3, KMS, Secrets Manager, Cognito, and CloudWatch Logs
- PHI never leaves BAA-covered infrastructure
- Sub-processor list available on request
- BAA renewal tracked as part of annual compliance review
ℹ️
18 HIPAA Identifiers Protected
Names, geographic data, dates (except year), phone, fax, email, SSN, medical record numbers, health plan IDs, account numbers, license/certificate numbers, VINs, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifier. All stored as encrypted
BYTEA in the phi schema.PHIPA — Personal Health Information Protection Act
Ontario, Canada — provincial health privacy legislation
Collection & Purpose Limitation
- PHI collected only for the purpose of providing care to residents
- Purpose tracked at the data model level — no free-form PHI storage outside designated
phischema - Family members restricted to linked resident data via access-level controls
- Staff access scoped to their assigned facility via
app.current_facility_idsession variable
Individual Rights
- Residents can request access to their own PHI through the family portal
- Correction requests handled by facility admins with audit trail
- Data portability: structured export available for transfer of care
- Withdrawal of consent tracked in resident clinical profile
Safeguards
- Administrative: role assignment requires admin approval; staff onboarding checklist
- Technical: schema-level access control, column encryption, RLS, session management
- Physical: AWS data centres with SOC 2 / ISO 27001 certification
- Jurisdiction flag on every facility record determines which retention rules apply
Breach Notification
- Ontario IPC notified within required timeframe for reportable breaches
- Affected individuals notified as soon as reasonably practicable
- All breach events logged in
audit.access_logswith full context - Annual privacy impact assessment (PIA) conducted
FERPA — Family Educational Rights and Privacy Act
United States K-12 and special education records privacy law
Peer Record Protection
- Behavior Log, Retrospective Board, and Service Delivery notes are screened as they're typed for mentions of another enrolled student — each student has independent record rights under FERPA
- Group session notes are kept general; each student's individual result is stored in their own record, never in a shared note
- The same check runs again server-side on save (
POST /api/progress-notes/screen) — enforced in two places by design so the client and API can never drift apart - A note that still names a peer is blocked from being shared with a family who has no right to that peer's record
Signed Attestation & Audit Trail
- Any save that changes what a student's record legally says — an edit, a new entry, or accepting AI-generated content — requires a signed attestation that the information matches the source document
- The signature travels on the same request that performs the save (
X-CS-Attestationheader, verified by caresphere-api's middleware) — the signature and the change it authorizes are one event, not two that could diverge - Recorded in the immutable
audit.access_logsalongside exactly which fields changed; before/after values stored in encrypted columns - The attestation wording itself is versioned, so the exact text a signer saw can be reconstructed later
COPPA — Children's Online Privacy Protection Act
United States protection for children under 13 — addressed through the school's consent
ℹ️
School-authorized use, not direct-to-child collection. CareSphere is deployed by schools and districts for school-authorized educational purposes — it is not marketed or offered directly to children, and student accounts are created and managed by the school, not by CareSphere. Under FTC guidance, a school may consent on a parent's behalf to an ed-tech provider's collection of a student's information for that school-authorized purpose, which is the basis CareSphere operates under rather than collecting separate parental consent directly. Consistent with CareSphere's Privacy Policy, student data is not sold, rented, or used for behavioral advertising, and no third-party analytics or advertising trackers are used.
Data Retention Policy
Jurisdiction-aware retention enforced at the database level
| Data Category | PHIPA (Ontario) | HIPAA (US) | Storage Tier |
|---|---|---|---|
| Resident PHI records | 10 years | 6 years | Aurora → S3 Glacier after 2yr |
| Audit & access logs | 10 years | 6 years | Aurora partitioned → S3 Glacier |
| Medication administration records | 10 years | 6 years | Aurora monthly partitions |
| Incident & breach reports | Indefinite | 6 years | Aurora — no archival |
| Session & authentication logs | 2 years | 6 years | Aurora → S3 after 90 days |
| Staff certification records | Duration of employment + 7yr | Duration + 6yr | Aurora active |
| De-identified analytics | No limit (no PHI) | No limit | Analytics schema |
Audit Capabilities
Immutable audit trail across all PHI access and system events
PHI Access Logs
Every read or write to the phi schema is recorded in audit.access_logs with user ID, role, action, resource, and timestamp. Emergency (break-glass) access is flagged separately.
Authentication Events
audit.login_events records every login attempt, MFA verification, token refresh, and logout — including IP address, device fingerprint, and user agent.
Configuration Changes
audit.cfg_change_history captures facility configuration, role assignments, and system settings changes with before/after snapshots.
Medication & Controlled Substances
Dual-witness controlled substance count logs (audit.medication_count_log) comply with DEA requirements. Every administration and waste event is audited.
Append-Only Grant Model
Application roles have INSERT only on audit tables — no UPDATE or DELETE. Records are immutable once written, preventing tampering.
SIEM Integration
The audit schema is exposed to Splunk and CloudWatch Logs Insights via a read-only role_audit_read role for real-time anomaly detection and quarterly compliance reporting.