HomePatientsClinicians ResearchReportsAI AnalyticsHIPAAContact Us
🛡️ HIPAA Compliance

Privacy isn't a feature.
It's the architecture.

Surfacing was designed from day one around a single constraint: patient data must never leave the patient's device. This document explains precisely how that works, and what it means for HIPAA compliance.

Compliance Posture

The short version

Because Surfacing operates entirely on-device with no server-side component, the vast majority of HIPAA technical safeguard requirements are satisfied by design — not by policy.

No PHI stored on Surfacing servers

We have no servers that receive or store patient data. The app is serverless by design.

AES-256 encryption at rest

The on-device database is encrypted using AES-256, the standard required by NIST and referenced in HIPAA technical safeguards.

No data transmission in normal use

The app functions fully offline. No network calls are made during normal logging, viewing, or filtering operations.

Export encryption is end-to-end

Exported files are AES-256 encrypted with a user-set password before leaving the device. No plaintext PHI is transmitted.

No third-party analytics or SDKs

The app contains zero third-party analytics, crash reporting, or tracking SDKs that could inadvertently transmit PHI.

Export HTML is fully self-contained

Exported HTML files contain no external script or resource references. They load entirely from local content — no network requests when opened.

Biometric & PIN app lock

The app requires biometric authentication or a user-set PIN before access, preventing unauthorized access if the device is lost.

Automatic session timeout

The app locks after 2 minutes of inactivity and when backgrounded — preventing unauthorized access on an unlocked device.

Healthcare Terminal Integration

Need delivery customized to your clinical environment?

We offer the ability to customize report delivery workflows for healthcare organizations — configuring export parameters, delivery formats, and integration pathways to meet your specific terminal and compliance requirements.

Customize Delivery to Healthcare Terminals — Contact Us

Customization options vary by organization type and clinical workflow. Contact us to discuss your specific requirements.

Technical Architecture

How the data flows (and where it doesn't)

Data at rest

// On-device storage stack Device Storage └── op-sqlite (encrypted SQLite) ├── Key: AES-256 via expo-secure-store │ (OS keychain / Android Keystore) ├── DB: entries, settings, audit_log └── Access: requires app unlock (Face ID / Touch ID / PIN) // Nothing leaves this boundary // during normal app operation
  • SQLite database file is encrypted at rest using AES-256
  • Encryption key stored in device OS keychain (not in app bundle)
  • Key protected by biometric/PIN gate — inaccessible while locked
  • No plaintext data ever written to disk
  • Audit log records all auth events, entry creates, and exports

Data in transit (export only)

// Export flow — patient-controlled Patient taps "Export" → App generates JSON payload → AES-256 encrypt with user password → Write to .html file (self-contained) ↓ Patient shares file to clinician (email, AirDrop, Signal, etc.) ↓ Clinician opens in browser → No network requests made → Decrypt with shared password → View data locally // Surfacing is never in this chain
  • Export is encrypted before leaving the device
  • Password set by patient — not stored by Surfacing
  • File transfer is peer-to-peer — no Surfacing intermediary
  • HTML file contains all libraries inline (no CDN calls)
  • Clinician views data locally — no upload, no cloud
HIPAA Technical Safeguards

Rule-by-rule breakdown

45 CFR § 164.312 establishes the Technical Safeguards required under the HIPAA Security Rule. Here is how Surfacing addresses each requirement.

§ 164.312(a)(1) — Access Control

Requirement: Implement technical policies that allow only authorized persons or software programs to access ePHI.

  • App requires Face ID, fingerprint, or 4-digit PIN to unlock
  • Automatic lock after 2 minutes of inactivity
  • Immediate lock when app is backgrounded or device locked
  • Encryption key is gated by OS-level biometric access controls
§ 164.312(a)(2)(i) — Unique User Identification

Requirement: Assign a unique name/number for identifying and tracking user identity.

  • Single-user device app — no multi-user account system required
  • Each device installation is implicitly a unique user context
  • Audit log captures all access events with timestamps
§ 164.312(a)(2)(iii) — Automatic Logoff

Requirement: Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

  • App locks automatically after 2 minutes of inactivity
  • App locks immediately when sent to background
  • Re-authentication required after every lock event
§ 164.312(a)(2)(iv) — Encryption & Decryption

Requirement: Implement a mechanism to encrypt and decrypt ePHI.

  • SQLite database encrypted at rest with AES-256
  • Encryption key generated from cryptographically secure random bytes
  • Key stored in OS keychain (iOS Secure Enclave / Android Keystore)
  • All exports encrypted with AES-256 before leaving device
§ 164.312(b) — Audit Controls

Requirement: Implement hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

  • On-device audit log records all auth attempts (success/failure)
  • All entry creation, modification, and deletion events logged
  • All export events logged with timestamp
  • Audit log included in exports for review
§ 164.312(c)(1) — Integrity

Requirement: Implement policies to protect ePHI from improper alteration or destruction.

  • Database encryption prevents external modification of data
  • No cloud sync means no remote alteration vector
  • Data deletion is explicit user-initiated action, not automatic
§ 164.312(e)(1) — Transmission Security

Requirement: Implement technical security measures to guard against unauthorized access to ePHI transmitted over electronic communications networks.

  • App transmits zero data in normal operation — no network calls
  • Exports are AES-256 encrypted before transmission begins
  • Patient controls transmission channel (may choose secure methods)
  • No Surfacing server ever receives exported data
Business Associate Agreements

Does Surfacing need to sign a BAA?

Short answer: In most cases, no.

A Business Associate Agreement is required when a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity. Surfacing's serverless architecture means we never receive, maintain, or transmit patient data — so the BAA obligation typically does not apply to our software.

When a BAA is not required

  • Patient uses the app independently to log their own data
  • Clinician recommends the app but does not receive data through Surfacing's systems
  • Research participant exports their own data and shares it directly with the research team
  • Exports are shared peer-to-peer (email, AirDrop) without passing through Surfacing

When you may want to consult your compliance officer

  • Your organization has a policy requiring BAAs for all third-party software used by staff
  • You plan to integrate Surfacing into a clinical workflow where the organization manages device or export handling
  • You're operating in a state with additional privacy regulations beyond HIPAA

We are happy to provide technical architecture documentation to your compliance team. Contact us.

FAQ

Common compliance questions

What encryption standard does Surfacing use? +
Surfacing uses AES-256 (Advanced Encryption Standard with 256-bit keys) for both the on-device database and the HTML export file. AES-256 is the encryption standard mandated by NIST for protecting sensitive government data and is widely accepted as the benchmark for HIPAA-compliant encryption. The encryption key for the database is stored in the device's hardware-backed secure enclave (iOS) or Keystore (Android), not in the application bundle.
Does the exported HTML file make any external requests? +
No. As of the current build, all JavaScript libraries (including the decryption library) are inlined directly into the HTML file. The file contains no external script tags, no CDN references, no web fonts loaded from external servers, and no analytics beacons. Opening an exported file is 100% offline — no data is transmitted when the clinician or researcher views it.
What happens if a patient loses their phone? +
The data on the phone remains encrypted and inaccessible without the device PIN/biometric. A factory reset or iOS/Android erase will destroy the data permanently — there is no cloud backup to recover from. This is intentional. Patients should be informed of this limitation: data loss means loss of that journaling history, but it also means a stolen device cannot be used to access their mental health records.
Can a clinician store the exported file in an EHR? +
Yes, with standard EHR security practices. The exported file is an encrypted HTML file — it can be attached to a patient record just like any other document. However, be aware that if the EHR stores the file unencrypted, the PHI protection shifts to the EHR's own security controls. The file itself is encrypted, so if the EHR storage is breached, the exported file remains protected as long as the export password is not also compromised.
Does Surfacing support multi-factor authentication? +
The app uses the device's native biometric authentication (Face ID, Touch ID, or fingerprint) which is a form of inherence-factor authentication. For devices without biometric hardware or enrollment, the app requires a 4-digit PIN. This PIN is stored in the device's hardware-backed secure enclave. Full MFA (two independent factors) is not currently implemented, as the app is designed for single-device personal use.
What logging does Surfacing provide for audit purposes? +
Surfacing maintains an on-device audit log that records: authentication attempts (success and failure with error code), entry creation events, entry modification events, export events with timestamp and count. This log is included in the encrypted export payload and is accessible to the patient and, by extension, any clinician who receives an export. The log does not leave the device except via the patient-controlled export process.
Compliance Inquiries

Talk to our compliance team

Need a technical architecture summary for your BAA review, IRB submission, or organizational risk assessment? We'll respond within 48 hours.

✓ Message received! Our compliance team will be in touch within 48 hours.

Nothing in this document constitutes legal advice. For compliance determinations specific to your organization, consult a qualified HIPAA attorney or compliance officer.